Html: <ol>.start getter does not seem to match browsers' behavior when reversed

Created on 7 Sep 2016 · 15Comments · Source: whatwg/html

https://html.spec.whatwg.org/#the-ol-element:dom-ol-reversed

[CEReactions] attribute long start;

The spec says:

If the ol element has a reversed attribute, then return the number of child li elements.

However, this does not appear to be the behavior of Chrome, Firefox or Safari.

Test case:
http://jsbin.com/tajuvuduxa/edit?html,output

Results:
Chrome / Safari:
Rendered (before load): 0
Unrendered (after load): 0
Rendered (after load): 3

Firefox:
Rendered (before load): 1
Unrendered (after load): 1
Rendered (after load): 1

I don't know why Firefox always returns 1. However, I know that Chrome and Safari return the number of _rendered_ child li elements.

compat normative change

Source

cdumez

All 15 comments

@domenic

cdumez on 7 Sep 2016

Related (but not the same): https://github.com/whatwg/html/issues/1617

Edge matches Firefox, so I guess this is a 2-2 tie. @Manishearth, you were fixing things in this area recently; any idea what the Firefox/Edge behavior is about? Maybe start just doesn't take into account reversed at all?

In any case, it seems like we unfortunately can't get away with the simple version in the spec. @zcorpan, from your work on innerText, how do we say "rendered", if we want to go with Blink/WebKit? Something about having associated CSS boxes?

domenic on 7 Sep 2016

https://html.spec.whatwg.org/multipage/rendering.html#being-rendered is used by ... lots of things 🙂

Referenced in:
3.2.7 The innerText IDL attribute
4.8.4 The img element
4.8.6 The embed element (2)
4.8.7 The object element (2)
4.8.9 The video element
4.10.5 The input element
4.10.6 The button element
4.10.20 APIs for the text control selections
4.10.21.2 Constraint validation
4.10.21.3 The constraint validation API
4.11.7 The dialog element
4.12.5 The canvas element
4.12.5.1.4 Text styles
4.12.5.1.8 Image sources for 2D rendering contexts
4.12.5.1.20 Filters
6.4.2 Data model (2) (3) (4) (5) (6)
6.4.3 The tabindex attribute
6.4.4 Processing model (2) (3)
7.8.9 Navigating to a fragment (2)
14.1 Introduction (2)
14.3.2 The page

zcorpan on 7 Sep 2016

@domenic It seems like Firefox just reflects here, and there's no indication that this is deliberate (https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLSharedListElement.h#56)

All browsers seem to renumber if the <ol> receives new child elements during partial page load (https://github.com/whatwg/html/issues/1617#issuecomment-236870490), so "number of current <li> children" might be the way to go. There shouldn't be a difference between rendered and unrendered IMO. Does blink/webkit implement this by querying layout?

Manishearth on 7 Sep 2016

Oh, I see, unrendered elements aren't numbered. Setting it to be the number of rendered child elements makes sense.

~~Firefox doesn't handle <ol reversed> with hidden elements correctly, http://jsbin.com/qemedakohu/edit?html,output is numbered as 3,2 instead of 2,1~~

Turns out that my changes to Gecko on #1617 fixed the hidden elements issue too, just that the change hadn't reached Firefox Dev Edition yet. Works in nightly.

cc @upsuper

Manishearth on 7 Sep 2016

I think it is possible to change Gecko's behavior to always use the render result. (We can probably just force a reflow when getting .start like everything else which requires that.) It is not clear what should be returned if the whole list is display: none. I guess it is hard for us to make that work as some may expect. I suggest we define that to return 0 if the ol is not rendered.

upsuper on 7 Sep 2016

That would fall out correctly if we say it must return the number of li children that are "being rendered", right? If the ol is not "being rendered", its children will also not be. (A note or example could be useful though.)

I think we also need a statement for non-CSS UAs (number of li children, or 0 if the ol is not "in a document"?).

Also note that the current spec says start simply reflects the content attribute. It also says "The start IDL attribute has the same default as its content attribute." but I can't find anything saying what the default is for the content attribute? It should say the default is the "starting value", or maybe change start to not be a reflecting attribute but instead say to return the "starting value" on getting and be like reflecting on setting.

zcorpan on 7 Sep 2016

Hmmm, wait, the spec says:

The reversed, start, and type IDL attributes must reflect the respective content attributes of the same name. The start IDL attribute has the same default as its content attribute.

which means, ol.start should just reflect the number from the content attribute, not the real "starting value" of the list, which makes sense, and it seems to me it matches most of other attributes. (I don't think we generally want DOM attribute depends on rendering result, do we?)

Also, I'm not particular happy with increasing number of functions which require layout, because that could slow down page significantly if author doesn't use it with care.

I think the most outstanding issue with the spec, then, is that, it doesn't give start a default value, and thus it is not speced what should be returned if there is no start attribute presents. The steps are for determining the "starting value", and start attribute itself is an input of the steps, not the result of that.

upsuper on 16 Oct 2016

👍1

We can take li.value as a reference. It has the same behavior among browsers that, if value attribute is not specified, it returns 0. I think start IDL attribute should have the same behavior.

upsuper on 16 Oct 2016

👍1

We could certainly try to move to that behavior, @upsuper. However, as http://jsbin.com/tajuvuduxa/edit?html,output shows, no browsers currently follow that for the default value. Chrome and Safari are being-rendered dependent, and Firefox and Edge always return 1. You raise a good point, though, that the sentence @cdumez quotes in the OP is not about the ol.start getter.

In my mind, the shortest path to simplicity and interop here is to converge on the Edge/Firefox behavior. That would mean updating the spec to say "The start IDL attribute has a default value of 1." (Right now it says "The start IDL attribute has the same default as its content attribute", but that doesn't make any sense.)

@cdumez, @tkent-google, how does that sound? We'd make ol.start no longer dependent on whether the element is being rendered. It would simply reflect the content attribute, and if there is no content attribute, it would fall back to a default of 1.

domenic on 17 Oct 2016

In my mind, the shortest path to simplicity and interop here is to converge on the Edge/Firefox behavior. That would mean updating the spec to say "The start IDL attribute has a default value of 1." (Right now it says "The start IDL attribute has the same default as its content attribute", but that doesn't make any sense.)

I think this is fine. I don't have preference on whether the default value should be 0 or 1. Picking the shortest path sounds good.

upsuper on 18 Oct 2016

I support converging on Edge/Firefox behavior.