Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
Daniel Holbert dholb...@mozilla.com wrote:
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[2] I only noticed one rendering difference -- IE11 honors border on
br, unlike the other browsers that I tested. (It still doesn't honor
e.g. display/width/height, though.)
I get different results on your test case for the bottom two tests. In
Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26
there isn't.
This matches a fault report that we had from a customer a few years about a
page that didn't lay out properly in our browser (but did in Opera) that I
tracked down to being that we permitted br elements to be styled, just like
Firefox (26.0) does. I've put a suitably anonymised version of the test
case on my own website:
http://www.metahusky.net/~stewart/css/br/br-rendering.html
And yes, the real page really did have the first line of its stylesheet as:
* { position: absolute; margin: 0px; float: left }
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 1/23/14 6:16 AM, Stewart Brodie wrote: I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Indeed. What Gecko does with br is basically to treat it like a special box type that has special sizing/painting/linebreak behavior. But we do still allow that box to be positioned/floated, just like an img... -Boris
Re: [whatwg] [mimesniff] The Apache workaround should not sniff random types
On 1/17/14 12:34 AM, Gordon P. Hemsley wrote: I have finally made this change. Please confirm that this is what you had in mind: https://github.com/whatwg/mimesniff/commit/d7bafc16ee480a5dea4c27d60dd5272388e022ce http://mimesniff.spec.whatwg.org/#rules-for-text-or-binary Yes, thank you. -Boris
[whatwg] Adding obsolete elements/attributes to indexes
Hi, The HTML spec has an Index section, with tables of all existing elements, attributes, and other things. I find this very helpful. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. That such features are in the spec at all, even though authors must not use them, probably means that Servo needs to implement them. However these features are not mentioned at all outside of the Obsolete features section, to it’s not easy to discover that they even exist if one does not think of look for Obsolete features specifically. To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. -- Simon Sapin
Re: [whatwg] Adding obsolete elements/attributes to indexes
On Thu, 23 Jan 2014, Simon Sapin wrote: To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. They're explicitly excluded to help with avoiding their discovery by authors. There's a link from any interface that has obsolete IDL members to the partial interface that defines those members. As far as non-obsolete elements go, I think the only requirements in the obsolete section are regarding these obsolete IDL members. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. Do you mean a type IDL attribute or a type content attribute? No IDL attributes are listed in the index. I don't know what it really means for an element to have a content attribute, from an implement's persective. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding obsolete elements/attributes to indexes
On 23/01/2014 08:54, Ian Hickson wrote: On Thu, 23 Jan 2014, Simon Sapin wrote: To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. They're explicitly excluded to help with avoiding their discovery by authors. I see. I still wish there was a version of the indexes for implementers :) There's a link from any interface that has obsolete IDL members to the partial interface that defines those members. As far as non-obsolete elements go, I think the only requirements in the obsolete section are regarding these obsolete IDL members. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. Do you mean a type IDL attribute or a type content attribute? No IDL attributes are listed in the index. I don't know what it really means for an element to have a content attribute, from an implement's persective. I’m talking about HTML attributes. In this case li type=AFoo/i affecting rendering compared to just liFoo/li. Perhaps elements having an attribute is not the right term, but a content attribute having meaning for the UA? -- Simon Sapin
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 01/23/2014 03:16 AM, Stewart Brodie wrote: [2] I only noticed one rendering difference -- IE11 honors border on br, unlike the other browsers that I tested. (It still doesn't honor e.g. display/width/height, though.) I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Yeah -- sorry, I thought up those last two testcases (applying float and position:absolute to br) a bit later, after I sent my initial email. (which is why I didn't mention them as a rendering difference) So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). ~Daniel
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 1/23/14 1:54 PM, Daniel Holbert wrote: So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). IE11 shows linebreaks on your last two testcases there. -Boris
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On 1/22/14 6:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/22/14 8:14 PM, Bruno Racineux wrote:
Meanwhile, is there a way in which all vendors can prevent their
pre-loaders from preloading (and loading at all for that matter) any
img
that has either: An html5 hidden attribute
This is feasible.
or display:none
This is not really. The preload scanner has no idea bout styles.
Then how come it is the case right now for both:
object style=display:none data=image.png
As well as:
head
style
.dn { display:none; }
/style
head
body
object class=dn data=image.png
body
Not only the pre-loader doesn't load the data-src
but image.png doesn't actually load at all.
The above suggested to me that it is possible, as it seems to be what's
currently in place in Webkit for object as image resource.
Is object treated as such a Bug then?
I think it's safe to say that, for the browser to load assets marked as
'display:none;' makes little sense
script elements are display:none, note.
So are link elements. Both get preloaded.
Nods, I understand it gets complicated with that notion.
And people do in fact depend on display:none images being preloaded on
the web today. People paint those images to canvases, unhide them and
expect them to show immediately, etc.
Well legacy behavior has made it so... just seems quite flawed in
responsive design context where you'd expect the ability to set resources
in the DOM with some control as to wether they ought to load or not,
rather be forced to have *all of them* preloaded.
What bugs me the most is that a developer's expectations is superseded by
a feature (the preloader) with different implementation per browser
engine, that are neither documented (in plain English) nor specced out by
W3C or WHATWG standards. As hard as it is, and notwithstanding the
benefits of the preloader(s), this is not good and keep developers
uninformed as to what to expect...
The lack of such resource control can be a huge waste of bandwidth in
collateral damage along the benefits of the pre-loader. And in the case of
responsive images, it prevents us from implementing any simple straight
forward js solutions.
Anyway, to come to the point of this new parallel thread, this leads me to
a suggestion:
'HIDDEN' as [resources control]:
Could 'resource control' be an associated spec of the 'hidden' attribute?
The semantics seem compatible with the specs implied by 'hidden'?
Being that: hidden Specifies that the element represents an element that
is not yet, or is no longer, relevant [1]. That suggest it may not be
needed at all and if so, why load it's associated resources?
Using the currently abandoned [2] 'postpone' attribute specs, 'hidden'
added specs
become something along the lines of:
'This value indicates that the User Agent MUST not start downloading the
resource associated with the element until either the bounding box of the
element is inside the User Agent's interpretation of the Document's
viewport, or the element has been styled such that its hidden property is
removed.'
Hidden being just a boolean property easy to handle by the pre-loader.
And also possibly have it set on container elements that aren't
visible. i.e. Doing what postpone intended.
That would give developers at least one way in which they can put a
'conditional load' on selected resources with the ability to bypass the
pre-loader as well as reducing network costs, without the associated
conflict with display:none;
And then maybe IE will decide to implement 'hidden' as deemed worth such
updated specs and role? (although not completely sure why IE hasn't
implemented 'hidden' yet...)
What do you think?
[1] http://dev.w3.org/html5/markup/global-attributes.html
[2] The WG agreed to scope the spec back to lazyload and work from there
http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0099.html
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On Thu, Jan 23, 2014 at 6:13 PM, Bruno Racineux br...@hexanet.net wrote:
On 1/22/14 6:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/22/14 8:14 PM, Bruno Racineux wrote:
Meanwhile, is there a way in which all vendors can prevent their
pre-loaders from preloading (and loading at all for that matter) any
img
that has either: An html5 hidden attribute
This is feasible.
or display:none
This is not really. The preload scanner has no idea bout styles.
Then how come it is the case right now for both:
object style=display:none data=image.png
As well as:
head
style
.dn { display:none; }
/style
head
body
object class=dn data=image.png
body
Not only the pre-loader doesn't load the data-src
but image.png doesn't actually load at all.
You're assuming that object preloads at all.
Boris isn't saying that making the preload scanner care about styles
is a bug, he's saying it's *impossible* (unless your preload scanner
triggers so late as to be a literally-just-before-load scanner).
~TJ
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On 1/23/14 9:13 PM, Bruno Racineux wrote:
Then how come it is the case right now for both:
object style=display:none data=image.png
Gecko's preloader never preloads objects. There are various reasons
for this, but the most important one is that in practice it doesn't
matter for actual web pages and hence no one has bothered to write the
extra code to make it work.
Not only the pre-loader doesn't load the data-src
but image.png doesn't actually load at all.
How did you determine that last, if I might ask?
I just tested in Gecko and Gecko does in fact load the image if the
above markup is used. Normal load, once the element has been created,
not preload.
It's not trivial to tell that with an image, but here's a testcase that
makes it crystal clear what's going on:
!DOCTYPE html
object style=display: none
data=data:text/plain,I_GOT_LOADED
/object
script
onload = function() {
var obj = document.querySelector(object);
alert(obj.contentDocument.documentElement.textContent);
}
/script
This works just fine in Gecko. It looks like WebKit/Blink do something
weird here, but that just sounds like a bug.
Well legacy behavior has made it so... just seems quite flawed in
responsive design context where you'd expect the ability to set resources
in the DOM with some control as to wether they ought to load or not,
Sure. That's why there's all this discussion about controlling
precisely that!
Could 'resource control' be an associated spec of the 'hidden' attribute?
It bothers me, at first glance, to overload the attribute to mean
different things. I predict people will appear who want the hidden
thing to hide but still want loading/preloading.
It would be better to just have a separate attribute for the separate
task if we go this direction.
-Boris
