Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
(2013/11/02 9:59), Boris Zbarsky wrote: > I can obviously adjust our in-tree tests, but this test was part of > jQuery's regression test suite, and I would be slightly surprised if > there's no one out there using jQuery 1.2.6 (or later, up until the code > went away; I did check that jQuery 1.10.2 no longer has the code cited > above) and if they don't run into this issue. :( Not that I am very familar with jQuery's history, but the cited code seems to be pre-Sizzle selector implemention[1], and therefore 1.2.6 should be the last jQuery version with this bug. I assume Mozilla testsuite means that getElementById on elements are roughly compatibile with jQuery 1.3+ even if they are actually using those[2]. That's pretty lucky, I think :) It would still be a good idea to run the lastest tests in Sizzle with jQuery 1.3 with the getElementById on elements impmentation to see if there's breakage, but my guess is no. [1] The exact change seems to be this one https://github.com/jquery/jquery/commit/c85243dfc4b09e6bb87532f2025f686b6ae45a22 [2] https://github.com/jquery/jquery/blob/1.3/src/selector.js#L343 Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Parse errors for invalid characters
(2013/09/06 6:08), Geoffrey Sneddon wrote: > The phrasing content section states: > >> Text nodes and attribute values must consist of Unicode characters, >> must not contain U+ characters, must not contain permanently >> undefined Unicode characters (noncharacters), and must not contain >> control characters other than space characters. This specification >> includes extra constraints on the exact value of Text nodes and >> attribute values depending on their precise context. > > And the pre-processing the input-stream section states: > >> Any occurrences of any characters in the ranges U+0001 to U+0008, >> U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters >> U+000B, U+FFFE, U+, U+1FFFE, U+1, U+2FFFE, U+2, U+3FFFE, >> U+3, U+4FFFE, U+4, U+5FFFE, U+5, U+6FFFE, U+6, >> U+7FFFE, U+7, U+8FFFE, U+8, U+9FFFE, U+9, U+AFFFE, >> U+A, U+BFFFE, U+B, U+CFFFE, U+C, U+DFFFE, U+D, >> U+EFFFE, U+E, U+E, U+F, U+10FFFE, and U+10 are parse >> errors. These are all control characters or permanently undefined >> Unicode characters (noncharacters). > > Note the first uses "Unicode characters", the second "characters" — the > former excludes surrogates as a conformance requirement. > > Note that every disallowed non-surrogate character is a parse error. Except U+ or am I missing something? > Therefore, it would make sense to make surrogates parse errors. > > It should be noted that they can only occur in the input stream if they > come from script (as they cannot be decoded from the input byte stream > as the decoders will never emit a surrogate). which means that this seems ... cubersome ... to implement in a conformance checker. Which reminds me, does # Conformance checkers must report at least one parse error # condition to the user if one or more parse error conditions exist # in the document and must not report parse error conditions if none # exist in the document. Conformance checkers may report more than # one parse error condition if more than one parse error condition # exists in the document. mean validator.nu and Firefox view source are non-conforming because they do nothing about document.write() ? I think we should exempt conformance checkers from scripts instead. Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] HTML differences from HTML4 document updated
(13/05/07 17:00), Simon Pieters wrote: >> Since WHATWG does not use a proper name for its version (the title is >> just "HTML"), I think the only way to refer to it properly is to >> prefix it with "WHATWG". This would lead to the title >> >> "Differences of HTML5 and WHATWG HTML from HTML 4.01" > > Here "HTML5" is supposed to refer to "W3C HTML5 and W3C HTML5.1"? Seems so. Is there a concern here? > How about I go back to the original title "Differences from HTML4"? > http://wiki.whatwg.org/wiki/Differences_from_HTML4 Or perhaps "Changes, News Features, and Fixes from HTML4" ? (/me is looking at GCC release note) Or * Differences of W3C HTML5/WHATWG HTML from HTML4 * Differences of WHATWG HTML/W3C HTML5 from HTML4 * HTML5 differences from HTML4 (the W3C title) Anyway, I agree that "HTML differences from HTML4" sounds confusing and any of the above is better. Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
(13/04/23 16:44), Peter Occil wrote:
> I believe there should be a DOM attribute that returns the language
> of a node, as defined in section 3.2.3.3 "The lang and xml:lang
> attributes".
What's your use case? If you want to style a particular language then
there's the CSS :lang() pseudo-class.
Use cases are important because otherwise I think there are very few
pages with multiple lang attributes...
> While there is a "lang" DOM attribute, it's inadequate because it's
> only affected by the element's "lang" content attribute.
That's true. However, if the case isn't important, we can do tree
traversal (modulo HTTP Content-Language header and pragma) or exhaust
element.matchesSelector(":lang(xxx)").
> Also, I don't see a way to get the "language of a node" otherwise,
> especially since it depends not only on "lang" and "xml:lang", but
> also on the HTTP Content-Language header, which may not be possible
> to retrieve with existing JavaScript methods, as far as I can tell.
Indeed.
Cheers,
Kenny
--
Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A question about the drawimage() canvas function
(13/03/02 5:59), Glenn Maynard wrote: > I recommend leaving Firefox alone and changing WebKit (and the spec) to > match Firefox, because we already have interop (at least in the cases I > tested) between Firefox and IE, and we already have interop during loads in > all three. Changing WebKit to throw after loading will get everyone doing > the same thing--changing Firefox will still leave IE out. > > (I haven't tested with IE10, FWIW, only IE9.) IE10 behaves the same in your test case. (13/03/02 6:45), Rik Cabanier wrote: > Sorry about being unclear. Yes, I meant in addition of. > So: > - add your suggested step 1 > - change HTMLImageElement from original step 2 to CanvasImageSource Did you mean to say "change *HTMLCanvasElement* from original step 2 to CanvasImageSource" here? The original step 2 has # If the image argument is an HTMLCanvasElement object with either a # horizontal dimension or a vertical dimension equal to zero, then # the implementation throw an InvalidStateError exception and return # aborted. (13/03/02 9:41), Glenn Maynard wrote: > But why does it throw this exception in the first place? It's a weird > special case. Blitting a zero-size image should do nothing, just like > drawImage(src, 0, 0, 0, 0). Just curious. Does it have to be SVG for an image to be zero-sized? Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] hidden="" should be "display:none !important" in the UA stylesheet
There's relevant discussion in Bugzilla too [1].
(12/11/14 5:49), Edward O'Connor wrote:
> I don't recall if this was in person or in email, but I think Tab made a
> compelling argument in favor of changing the implementation of hidden=""
> to be
>
> [hidden] {
> display: none !important;
> }
>
> in the UA stylesheet.
Would it be possible to treat this as !important presentation hint so
that it overrides all author-level non-important declarations but not
important ones? So that for Hixie's use cases, you can still do
[hidden] {
display: block !important;
opacity: 0;
}
. This is assuming that Hixie's use cases are not strong and that this
is implementable. All other presentation hints are not !important so
this might indeed not be implementable.
(12/11/14 8:59), Glenn Maynard wrote:
> On Tue, Nov 13, 2012 at 4:38 PM, Ian Hickson wrote:
>
>> You just have to write .thing:not([hidden]), or have an explicit
>> [hidden] rule. It's not a big deal.
>
> This is a cumbersome, hackish workaround. I shouldn't have to care
> about whether an element might have its @hidden property set when I
> set an element to inline-block, and I shouldn't need to hack up my
> CSS when I hide an element.
The less hackish way is probably to remember to add
[hidden] {
display: none !important;
}
at the beginning of your stylesheet and remember not to use !important
'display' later. This is pretty much equivalent to the suggestion above.
(12/11/14 8:59), Glenn Maynard wrote:
>> The better solution would be for us to cascade the display type separately
>> from the rendering tree inclusion/exclusion decision, but that boat sailed
>> a long time ago.
>
> Surely nothing prevents adding a CSS property, eg. "shown: no", which takes
> precedence over display when set to "no" and does nothing when set to
> "yes". It's probably too late to change @hidden to use it, though maybe
> not; it would probably break a roughly equal number of sites as the change
> proposed here would.
So there's 'display-box: none'[2] in css-display-3, but yes, by the time
browsers ship this property, if browsers ever do, it's probably too late
to change the UA style for [style]. And also, I don't see how this
solves Tab's problem because 'display' expands to 'display-box' too.
(12/11/14 5:49), Edward O'Connor wrote:
> Consider a bunch of thingies, represented in the DOM with a pile of
> s. Some of them are hidden.
>
> [...]
>
> These thingies are flexboxes:
>
> .thing {
> display: flex;
> }
You can do 'display-outside: flex' in the future, but it seems a bit
long and if you actually remember this problem, you should just place
[hidden] {
display: none !important;
}
at the beginning.
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277
[2] http://dev.w3.org/csswg/css-display-3/#the-display-box
Cheers,
Kenny
--
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A plea to Hixie to adopt
(12/11/08 1:48), James Graham wrote: > I think that finding the main content of a page has clear use cases. We > can see examples of authors working around the lack of this feature in > the platform every time they use a "skip to main" link, or (less > commonly) aria role=main. I believe we also see browsers supporting > role=main in their AT mapping, which suggests implementer interest in > this approach since the solutions are functionally isomorphic (but with > very different marketing and usability stories). > > I think the argument that the Scooby Doo algorithm is deficient because > it requires many elements of a page to be correctly marked up, compared > to which requires only a single element to get the same > functional effect, has merit. Hixie's another argument, if I understand correctly, is to use in place of this role. I think the Web is probably full of mis-used already such that using the first in document order has no chance to work out, but it would nice if this can be verified, even though I can already imagine that an author is unlikely to mark up the main content with when the main content isn't an article in English sense. > The observation that having one element on a page marked — via class > or id — "main" is already a clear cowpath enhances the credibility > of the suggested solution. On the other hand, I agree that now > everyone heading down the cowpath was aiming for the same place; a > wrapping the whole page, headers, footers, and > all is clearly not the same as one that identifies the extent of the > primary content. Right. So, assuming "skip to main" is the only use case for , which I am not sure if Steve agrees, I think the proposal should use strong wording to prevent such misuse and the proposal should include one example of such misuse and explains it. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Meta "bugreport" proposal
Overall, I think this is interesting and something some browser developers would really like to see, as they often want to report site compatibility issues. Therefore, I think you might want to write down a proposal that's more detailed and create an entry in the registry[1] so that people know such an idea exists. I don't think it's particularly important to get an "Accepted" status and popularizing the idea is probably more important. Also, you might want to share your idea on public-vo...@w3.org[2] as there are more people on that list who are in general more interested in features like this. (12/10/31 17:21), Nicolas Froidure wrote: > The uri could be : > - mailto: to send a report by mail (ex: mailto:webmas...@example.org) > - http: to send the bug report a a simple HTTP POST request (ex: > http://example.org/bugreport). > - bug: something more customizable to allow webmasters to fit bug > reports with their systems (ex: > bug:http?uri=/bug.dat&method=POST&captcha=/captcha.jpg ) I am not sure a new scheme is a good idea. For embedding data in a URL, you might consider something like data:text/plain,http?uri=/bug.dat&method=POST&captcha=/captcha.jpg but I am not an expert on this to say whether this is a good idea. > - etc (ws:, irc: ...) > > In order to test this i just made a Chrome extension illustrating how > browsers could handle this meta markup : > https://chrome.google.com/webstore/detail/bugmeback/hgmagcomobmjhaomdoihiggpdekaehmg > > The code is there : https://github.com/nfroidure/BugMeBack Thanks for moving this forward with a concrete implementation instead of an abstract idea! I am not familiar Chrome extension API and what chrome.extension.sendRequest does, but if it does send an email when @href is a mailto: URL, you might want to either: 1. Discuss with whoever creates the entry for rel=webmaster in [1] to see if either rel=webmaster can be dropped or rel=bugreport can be merged into it. 2. Extract mailto: URL from rel=webmaster too and treat it as if it is rel=bugreport. > Are you interested in that kind of approach for bug reporting ? I think a lot of people do dream of an automatic Web but unfortunately it's never easy to make one. [1] http://wiki.whatwg.org/wiki/RelExtensions [2] http://lists.w3.org/Archives/Public/public-vocabs/ Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Exposing visible string of an input field
(12/09/07 17:49), TAMURA, Kent wrote: > Proposal: > > I'd like to propose adding new IDL attribute to HTMLInputElement. > readonly attribute DOMString rawValue; If I understand the main use case correctly. This probably should be called displayValue or something. > It returns text content which a user actually see in an input field. > * For text, search, url, tel, password types, it's equivalent to 'value' > IDL attribute. > * For email type, it returns a string which a user is editing. It means it > returns a string without Unicode -> Punycode conversion and without > normalization of whitespace and commas. > * For number type, it returns user-editing string. If a user typed '123+++' > into a number field, rawValue would be '123+++' as is. > * For date, datetime, datetime-local, month, time, week, the attribute > returns a string in a field. If a field is text-editable, it should return > user-editing string like email and number. If a field has a fixed > localized date/time string chosen by a date/time picker, the attribute > should return the localized string. > * For submit, reset, button types, the attribute returns a label which the > field shows. e.g. 'Submit' for without value > attribute. > * For other types, should it return an empty string? What about type=file ? > Use case: > > - We can enable text field selection APIs for email, number, and other > types So you want to enable select() etc. for these types? Are there real needs here? > - JavaScript-based screen readers can read user-visible content of input > fields. For localized strings (date, datetime, datetime-local, month, time, week), it doesn't seem to be difficult to hard-code the string conversion functions into a JavaScript screen reader. For inputs that are being edited (date, datetime, datetime-local, month, time, week, number), I wonder if we should instead remove restrictions like this: # User agents must not allow the user to set the value to a non-empty # string that is not a valid floating-point number. and just let .value returns the raw input while a user is editing the value and let value sanitization algorithm happen afterward. > Strings returned by rawValue attribute may be browser-dependent and > locale-dependent. However it would be useful. The proposed feature sounds a bit messy to me... Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Quirks mode handling of rowspan="0"
(12/09/03 8:11), Boris Zbarsky wrote: > Per HTML5 spec, rowspan="0" should span to the end of the table section. > > WebKit seems to not implement this at all. > > Opera implements this in quirks and standards mode. > > Gecko implements this in standards mode only; in quirks mode, > rowspan="0" is treated like rowspan="1". When we last tried to do the > "right" thing in quirks mode, back in 2003 or so, we ran into site > compatibility issues, hence the current setup. > > I don't know what Trident does here; worth testing. IE seem to follow WebKit in every mode I tested with. (Test case[1]) > In any case, my suggestion is that in quirks mode, rowspan="0" not be > supported. No opinion here. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1734 Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Wasn't there going to be a strict spec?
(12/08/11 8:41), Erik Reppen wrote: > Thanks Hugh. I had mistakenly been thinking of XHTML5 as something that > never happened rather than merely HTML5 served as XML which hadn't really > occurred to me as being a viable option. I look forward to messing with > this. This is precisely what I wanted to be able to do. Yep. I would encourage you to play with XHTML5 (application/xhtml+xml) more and report bugs to browsers. When I still had interest in application/xhtml+xml (back in 2007?), I got troubled by all the differences in the DOM APIs. I think currently most JS framework probably doesn't support XHTML5. After playing XHTML5, if you still think browsers should implement yet another mode, you should probably say why XHTML5 is bad and why you don't just use it. If you have proposals for how some of the DOM APIs in XHTML5 should work, you might want to follow the instruction on the top of relevant specs (DOM Parsing and Serialization[1] basically) and send feedback. [1] http://html5.org/specs/dom-parsing.html Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] A usecase
(12/06/08 7:28), Ian Hickson wrote: > It still seems like a bit of an edge case, so I think it's ok for us > to continue to rely on @import for this for now. But we should keep > an eye out for how often people use this technique; if it is indeed > something that comes up a lot, then introducing scoped="" on > would make sense. I don't know if this counts as a lot or not, but besides (12/03/03 2:03), Kang-Hao (Kenny) Lu wrote: > A reader of html5doctor had the same problem too[1] and I can > certainly image other people being confused by this. > > [1] http://html5doctor.com/the-scoped-attribute/#link which I mentioned, Googling the string "html5 scoped @import" gives me the following sites which mention this technique, even if there's only one browser supporting the 'scoped' attribute at the moment: [2][3][4] I haven't examine these use cases to see if they are counted "valid" or not, but I think it's unfair to say this is an edge case. [2] http://www.codingforums.com/showthread.php?t=242411#postcount1154993 [3] http://www.webdirections.org/blog/on-the-abominable-proposed-html5-scoped-attribute-for-style-elements/#comment-222761 [4] http://www.peterrknight.com/loading-javascript-and-css-mid-page-html5-wordpress-passing-validation-part-1/ > On Fri, 2 Mar 2012, Tab Atkins Jr. wrote: >> >> Do this instead: >> >> >> >> @import "3rd-party-theme/user-published-20120302133702.css"; >> >> function >> class="identifier">test... >> > > That's a good workaround, but if the use case is something we want to > actually address, I think supporting here makes sense too. A good portion of the use of would just be something like this, and I still don't see good reasons why <style scoped>@import "3rd-party-theme/user-published-20120302133702.css"; is preferable to when the later is clearly easier to think of (or otherwise Gray or the the reader of html5doctor wouldn't have asked this). Tab mentioned (12/03/03 2:13), Tab Atkins Jr. wrote: > As well, right now the *only* purpose of a in the is to > function as a hidden source of url-flavored data for Microdata, if you > find empty s distasteful. but given that Microdata already breaks this tradition, I don't see how it is still relevant. Cheers, Kenny
Re: [whatwg] , `img set`, and polyfills
(12/05/15 7:17), Mathew Marquis wrote: > It’s worth noting that a practical polyfill may not be possible when using > `img set`, for reasons detailed at length elsewhere: > http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ > http://www.netmagazine.com/features/state-responsive-images > > Long story short: attempting to write a polyfill for `img set` leaves us in > the exact situation we were in while trying to solve the issue of responsive > images strictly on the front-end. We would be saddling users with a redundant > download—first for the original src, then for the appropriately-sized source > if needed. > > Where the new element would be all but ignored by existing browsers, > efficient polyfills become possible. In fact, two `picture` polyfills exist > today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills Sorry but I don't understand why as used around by these polyfills listed can't be used along . If your point is that some Web developers will not cater for NoScript users and chose to include in , I think those authors can use without @src too (if I understand correctly). Cheers, Kenny
Re: [whatwg] Relation between "bordercolor" and "border" attributes
(12/03/06 17:58), Kishore Bolisetty wrote:
> But it doesn't talks about the behaviour - what if border is not specified
> but bordercolor is specified? Looks like browsers have taken their own
> implementations on this, Opera and Mozilla displays bordercolor only if
> border is specified, where as Safari displays bordercolor assuming a
> default border.
I'll add one more testing result. IE9 and IE quirks mode match Opera and
Mozilla's behavior.
> Which one is correct behaviour? Is it not necessary to explicitly state
> this in the spec?
I don't know what is correct but Safari is certainly less interoperable
here, and the spec matches the interoperable behavior. That is, I think
the spec is pretty clear: bordercolor only changes the border color, not
whether the border shows up or not ('border-style') or border width
('border-width').
(12/03/07 0:35), Tab Atkins Jr. wrote:
> This behavior depends on the browser's default stylesheet, and whether
> they default borders to "border-style: solid; border-color:
> currentColor;" or "border-style: solid; border-width: 0px;". Browsers
> are allowed to do either.
I don't understand your examples. I think you are probably suggesting
that browsers are allowed to put "table[bordercolor] { border-style:
solid}" in the default stylesheet, but I don't think that's the case
since it makes the browser that does this not "supporting the suggested
default rendering".
Cheers,
Kenny
Re: [whatwg] A link[scoped] usecase
(12/03/03 2:13), Tab Atkins Jr. wrote: >> On the other hand, why is it bad for browsers and the Web platform to >> support @scoped on ? > > Because it's an additional feature that adds no power. I doubt most people will see this as a new feature. If implementation cost of @scoped on isn't much, this really is just different opinions on the syntax. > As well, right now the *only* purpose of a in the is to > function as a hidden source of url-flavored data for Microdata, if you > find empty s distasteful. I wonder how important keeping the out of is. Perhaps the Web platform would be cleaner that way? I don't know. > @import is just fine - it lets you modularize your files without having to > change/add s in all your documents. I don't understand this statement. Could you explain more? >> The argument here is that I think @import might have >> usability problem (and also you need more work if want to switch the >> style. This could happen, for example, when the theme panel as described >> in this use case is a with a .). A reader of html5doctor >> had the same problem too[2] and I can certainly image other people being >> confused by this. > > What usability problems are you suggesting? I don't have the resource to do a well-designed usability experiment here, but I am almost very sure if you: 1. Gather a bunch of Web Developers who didn't know . 2. Teach them