Re: [whatwg] External document subset support
2009/6/19 Kristof Zelechovski giecr...@stegny.2a.pl:
You can easily include a cross-domain script using a cross-domain DTD; just
attach the malware as
!ATTLIST body onload CDATA “{ sniper.shoot(); }”
and hope for the worst.
Chris
You need to own the external subset, though, in order to add that
!ATTLIST. It is like saying that shared JS libraries are dangerous
because you import code from other sources.
Giovanni
Re: [whatwg] HTML 5 suggestion for TABLE element
2009/6/10 Dahal, Biswa biswa-da...@uiowa.edu: Hi, I am a developer and as I was going through the draft for HTML 5 at: http://dev.w3.org/html5/html-author/#tabular-data, I could not find a common use-case that should be supported. That is not the HTML5 draft, that is the HTML5 for Authors (a guide, in practice, not a normative specification). The HTML5 draft is at http://dev.w3.org/html5/spec My recommendation is to add an attribute “scroll: scolling (default) | fixed” in thead and tfoot to allow them to be fixed (non scrolling headers / footers ). This is currently performed through CSS hacks and is not consistent across browser implementations. Example CSS implementation: http://www.ssi-developer.net/css/non-scrolling-table-hdr.shtml to understand the effect. Alternatively, you can open Excel and use “freeze panes” to view the effect. This does not belong to HTML, it belongs to CSS Tables Level 3, in defining the meaning of height and overflow for table-row-groups (currently undefined). You should forward this suggestion to www-st...@w3.org Please let me know if you acknowledge this. Thanks, BD Software Developer Giovanni
Re: [whatwg] Reserving id attribute values?
2009/6/10 Ian Hickson i...@hixie.ch: On Tue, 19 May 2009, Brett Zamir wrote: In order to comply with XML ID requirements in XML, and facilitate future transitions to XML, can HTML 5 explicitly encourage id attribute values to follow this pattern (e.g., disallowing numbers for the starting character)? Why can't we just change the XML ID requirements in XML to be less strict? Because you are not part of the XMLCore WG, because XML is a Recommendation and because ID has been a Name from the very beginning of SGML. If something should be changed, it is the HTML5 draft. Naturally it should be only an author conformance requirement. Also, there is this minor errata: http://www.whatwg.org/specs/web-apps/current-work/#refsCSS21 is broken (in section 3.2) I haven't done any references yet; I'll probably get to them in a couple of months. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Giovanni
Re: [whatwg] Two feature-suggestions for HTML5 (forms)
Please don't cross-post to w3 lists and to whatwg lists. 2009/6/8 Asser Nilsson asser.nils...@googlemail.com: Hi! There are two things in HTML5-forms that are often made with Active Technology like JavaScript, that would be very cool, if HTML5 could do these things without Scripting: 1. I've seen this at the online-dictionary dict.leo.org: they made a JavaScript-function, that you can type the word to translate without the text-box marked an the characters get in there. So, you don't have to mark the right textbox before you type, but you can type, no matter to look, if the box is marked. I think it would be a very nice feature for HTML5-forms if this would work without Scripting... E.g. an option for text-fields, that everythins typed on this site is typed into this field (even if it is not highlighted). What about setting the autofocus attribute on the page? Keys have various meaning in various points of the page and you should not change that, but you can get the equivalent effect (user doesn't have to click on the textbox). 2. In search-boxes Javascript often is used for send every written character to the server and the server return search-suggestions as-you-type. If this is possible without Scripting only with HTML/CSS this would be very cool. It is possible to do this with XForms, I guess. That is not exactly declarative but has less problems that pure Javascript (if you don't think that XForms is mainly implemented as Javascript, of couse) Of course, there are things where you need Scripting, but such basic features should be possible without scripting, only with HTML/CSS. (Many people deactivate Scripting.) Sorry for my bad english, but I really think these two things would be very nice features for coming versions of HTML. Greetings, Asser Nilsson Giovanni
Re: [whatwg] do not encourage use of small element for legal text (was: Pre-Last Call Comments)
2009/6/5 Jeff Walden jwalden+wha...@mit.edu: Do you seriously believe any client in an industry where he has to step carefully enough to worry about typographical formatting of legal notices is fool enough to follow a not-even-recommendation in the HTML5 specification over what his lawyer tells him is the correct thing to do? In that case, we may write: The small element represent small print, that is content that, while being as important as content is surrounding it (or even more important), the author tries to hide from the user or otherwise make less likely to be noticed without reading carefully. Note: common uses for this element are legalese, attributions, copyrights, disclaimers and the like. Jeff Giovanni
Re: [whatwg] SVG extensions to canvas
2009/5/5 Robert O'Callahan rob...@ocallahan.org: On Tue, May 5, 2009 at 4:35 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: What is embed used for? Flash and videos. Both have intrinsic sizes What is object used for? Videos, Java applets and Silverlight. They all have intrinsic sizes. In principal, maybe they do, but typically those sizes are not exposed to the browser and are not used in layout. This is an implementation problem (and likely a bug: if a don't specify width/height for video I should get the intrinsic size, not a default) Basically, for what concerns rendering (the element being replaced in the CSS meaning of term), img,embed,object,svg have intrinsic sizes (they may be rescaled, but this is ortogonal) SVG images often don't have an intrinsic size. What's the intrinsic size of this image? svg xmlns=http://www.w3.org/2000/svg; linearGradient id=g x1=0 y1=0 x2=1 y2=0 stop stop-color=red offset=0/stop stop-color=lime offset=1/ /linearGradient rect x=0% y=0% width=100% height=100% fill=url(#g)/ /svg That svg hasn't got intrinsic sizes, so it cannot be rendered on a canvas. This doesn't preclude the use of svg with intrinsic sizes, that are given only by width/height attributes on svg. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] Giovanni
Re: [whatwg] SVG extensions to canvas
2009/5/5 Robert O'Callahan rob...@ocallahan.org: On Mon, May 4, 2009 at 7:26 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: svg has an intrinsic size (like video,img, and embed/object), the other have not. video and img usually have intrinsic sizes, but embed/object/iframe usually don't. svg often does and often does not. What is embed used for? Flash and videos. Both have intrinsic sizes What is object used for? Videos, Java applets and Silverlight. They all have intrinsic sizes. Basically, for what concerns rendering (the element being replaced in the CSS meaning of term), img,embed,object,svg have intrinsic sizes (they may be rescaled, but this is ortogonal) Note that I didn't include iframe in this list, because it could be rendered as if the child document contents were inside the parent document, within the iframe (auto height given by elements content); or it could be rendered as a window, with intrinsic sizes given by width/height. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] Giovanni
Re: [whatwg] SVG extensions to canvas
2009/5/4 Oliver Hunt oli...@apple.com: On May 4, 2009, at 6:38 AM, Anne van Kesteren wrote: On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson i...@hixie.ch wrote: As far as I can tell this doesn't require any changes to HTML5, since the same applies here as applies to a regular img, right? Maybe you misunderstood, but the request was not about img referencing SVG, but passing an SVGSVGElement object directly to drawImage() and friends. I had certainly misunderstood :D I'm not sure this is a great idea, as like all other elements the size of an SVGSVGElement may be influenced by where it is in the DOM, which makes it unclear how drawImage(SVGSVGElement) should work, eg. should it use the natural size of the element, the size of the element according to its current location in the dom (and what happens if it's not in the dom?), or what? If HTMLImgElement uses the natural size, then SVGSVGElement should as well. The CSS properties set on img at its natural position in the DOM don't matter, so it is not really an issue. I believe drawImage should be left as it currently is (basically taking objects that are intrinsically bitmap-ish), and if we were to add an ability to draw an svg element into the canvas it should really be an simple drawElement(Element) method instead, after all, why restrict it it just to SVG elements? svg has an intrinsic size (like video,img, and embed/object), the other have not. --Oliver Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Alex Russell slightly...@google.com:
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
This is a bug, not a design constraint.
JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.
DOM = Document Object Model = a set of APIs for representing and
manipulating documents
If you need pure scripting interfaces, you can write your own library,
without reusing EventTarget, that has been used outside its scope with
debatable results. (what does event.stopPropagation() do for
XMLHttpRequest events?)
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
It's safe to fully ignore Java.
Why?
Moreover, is it safe to fully ignore Python or Perl? This is not the
opinion of the SVGWG, in SVGTiny12.
And Java bindings are provided by WebIDL and all DOM specifications.
Regards
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
2009/4/6 Ojan Vafai o...@chromium.org: On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack c...@mcc.id.au wrote: Ojan Vafai: 2) Add a css or xpath expression to fragment identifiers. Tthe iframe src can be set to http://foo.com#css(.foo #bar). Same as above applies. If there's no match, it's a noop. If there is a match, it scrolls the first one into view. Sounds like XPointer: http://www.w3.org/TR/xptr-framework/ Yes, it's a similar idea. XPointer seems focused on XML/XHTML, I'm not sure what it would take to extend the spec to include HTML. In addition, I don't really see the point of adding yet another element addressing scheme to the web. XPath and CSS selectors are already there and familiar to developers. Actually, XPointer is just the application of XPath in fragment identifiers of XML resources, but it is designed in a way that could allow a css scheme or anything else, if specified. Giovanni
[whatwg] [html5] Pre-Last Call Comments
A few comments, as requested by Ian Hickson.
- End of 2.2.1, a typo: JavsScript instead of Javascript
- From section 2.4.2 I don't understand if boolean attributes with
invalid values represent true or false. In addition, I don't
understand if an empty value is false (as in XHTML1.0) or true (as in
HTML4, because of the minimized syntax).
From my experience, I expect that the empty string (which is
equivalent to not specify the attribute at all) is false, and any
other value is true.
- In 2.4.3 I don't see the point of all the digression about
contentEditable, since it is noted that it doesn't work like that. I
would leave the note to just Note: The empty string can be one of the
keywords or Note: The empty string can a valid keyword
- In 2.4.4.3 (and maybe in other places) I would prefer [A|E]BNF
instead of the prose description of a floating point number. I'm also
not sure that the normative algorithm is needed.
I've also searched IEEE, IETF, ECMA, ISO and ANSI for another
normative version of the syntax and processing, but I've found none.
If you think that it is important to have it specified completely, you
may submit an ID, so future technologies won't need to rewrite it
again.
- The second paragraph in 2.4.5.6 is hard to understand because the
verb is at the end. I would rewrite as A week-year with a number *yr*
has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian
calendar that has a Thursday as its first day (January 1st), or if
*yr* where *yr* is a number divisible by 400, or a number divisible by
4 but not by 100. In all other cases it has 52 weeks
Also, don't rely on styles alone, use different words for identifiers
and prose. This includes also the Note following, where no styles are
applied and it is difficult to understand that year year is not a
typo but rather is the year numbered year.
- Can't be simply referenced CSS3 Color in 2.4.6?
This way, implementors could have body[bgcolor] { background-color:
attr(bgcolor,color,white); } in the default CSS instead of using HTML5
specific rules.
- In 2.4.9 a valid hash reference must be equal to an ID, name is
supported only for backward compatibility.
- No comments for the URL part (except that Web Addresses is different
in processing, and the proposed IRI-bis draft makes it unnecessary)
- Section 2.6 is superfluous: handling of application cache is
specified in the appropriate section, handling of HTTP requests and
caches is defined in RFC2616, handling of cookie is defined in the
appropriate RFC (I don't remember the number), handling of about:blank
is in the proposed about-uri-scheme ID.
In addition, serialized queue-based handling of resources should not
be mandated by the HTML5 specification (can't UAs be multi-threaded?)
- Rewriting 2.6.1 without the HTTP word is definitely better. Browsers
are not required to support HTTP, AFAIK. You can write a GET method
(because GET is anyway an English word), a response code (most
protocols have response codes) and metadata (instead of headers,
that SMTP, POP, FTP don't support)
- 2.6.2 should be implied by the HTTP-over-TLS RFC
- In section 2.7.1, in sentence Extensions must not be used for
determining resource types for resources fetched over HTTP., do you
mean File extensions, like .txt or .png, or User agent extensions
(additions to the algorithm)?
- Still in section 2.7.1, why the algorithm is a violation of RFC2616?
Because it is case insensitive? Because it allows spaces? Because it
does not imply ISO-8859-1 if no charset is explicit? Because it does
not imply ASCII for text/* mime types?
- Why don't you add ?xml to the sniffing table?
- In section 2.8, x-x-big5 is not a different encoding than big5,
it rather seems an alias (and as such should be submitted to IANA)
- Later in the same section, I don't understand why you don't support
those encodings, if the encoding declaration is explicit in the
protocol layer or is allowed by a different specification. For
example, XML allows EBDIC based encodings. In addition, I don't
understand why supporting UTF-32 or EBDIC means a change to the
algorithm, that are defined in terms of Unicode code points (very
similar to UTF-32 characters)
- In section 2.9.1, I completely don't understand the part about DOM
attributes of type HTMLElement, especially the subpart about setting.
- In section 2.9.5, instead of define DOMStringMap only for
EcmaScript, use explicit indexing operation in the IDL, add them the
[NameGetter] / [NameSetter] / [NameDeleter] attributes, and add a
[NoIndexingOperation] to the whole interface.
- In section 2.9.6 you discourage use of hasFeature. Firstly, if an
implementation says true and it is not compliant, it is not a spec
bug, it is an implementation bug. Secondly, to allow implementation
granularity, you could define more features (for example HTML 5.0,
XHTML 5.0, HTMLCanvas2D 5.0, HTMLSection 5.0, HTMLDatagrid 5.0,
HTMLMediaObject 5.0 etc.)
- In section 3.2.1, seems that interfaces other than
Re: [whatwg] Web Addresses vs Legacy Extended IRI (again)
2009/3/29 Kristof Zelechovski giecr...@stegny.2a.pl: It is not clear that the server will be able to correctly support various representations of characters in the path component, e.g. identify accented characters with their decompositions using combining diacritical marks. The peculiarities can depend on the underlying file system conventions. Therefore, if all representations are considered equally appropriate, various resources may suddenly become unavailable, depending on the encoding decisions taken by the user agent. Chris It is not clear to me that the server will be able to support the composed form of à or ø. Where is specified the conversion from ISO-8859-1 to UCS? Nowhere. If a server knows it cannot deal with Unicode Normalization, it should either use an encoding form of Unicode (utf-8, utf-16), implement a technology that uses directly IRIs (because Normalization is introduced only when converting to an URI) or generate IRIs with binary path data in opaque form (ie percent-encoded) By the way, the server should be able to deal with both composed and decomposed forms of accented character (or use none of them), because I may type the path directly in my address bar (do you know what IME I use?) Giovanni
[whatwg] Web Addresses vs Legacy Extended IRI (again)
(In this email I will use URL5 as a short for Web Addresses, as that
previously was the URL part of HTML5)
As subject says, this is the continuation of the thread about LEIRI vs
URL5 archived at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018929.html,
where discussion diverged to good vs bad standard and the adoption
of URL5 in other Internet-related technologies.
In this email I want to talk only about technical differences in the
processing requirements of URL5 and LEIRI.
Ian Hickson as repeatdly said that URL5 and (LE)IRI are different in
the processing model, last time in
http://lists.w3.org/Archives/Public/public-html/2009Mar/0693.html,
adding that the URL5 model is the one used by current applications.
I'm not sure about the last part of his sentence, but this is outside
the scope of this thread.
The current status is:
- RFC3986 to define URIs, their validity and their processing
- RFC3987 to define IRIs, their validity, their processing and their
conversion to URIs
- the IRI-bis draft at
http://www.w3.org/International/iri-edit/draft-duerst-iri-bis.html
to define LEIRIs and their conversion to IRIs
- the URL5 document, to define Web Addresses and their conversion to URIs
Let's see if we can find some differences in those documents, that
really need a different technology.
Well, hypertext locations, either URIs, IRIs or URL5s, are sequences
of characters, so the difference must be in the handling of those
characters.
Reasons are taken from the IRI-bis draft and from the URI RFC. Note
that invalidity for URL5 does not mean parse error.
= U+ - U+001F: Unicode control C0:
- in a URI: invalid, must be percent-encoded. Processing: stop
- in a IRI: invalid, must be percent-encoded. Processing: stop
Reason: There is no way to transmit these characters reliably except
potentially in electronic form. Even when in electronic form, some
software components might silently filter out some of these
characters, or may stop processing alltogether when encountering some
of them. These characters may affect text display in subtle,
unnoticable ways or in drastic, global, and irreversible ways
depending on the hardware and software involved.
- in a LEIRI: valid. Processing to IRI: percent-encode
- in a URL5: invalid. Processing to URI: percent-encode
= U+0020: Space
- in a URI: invalid, must be percent-encoded. Processing: stop
- in a IRI: invalid, must be percent-encoded. Processing: stop
Reason: Some formats and applications use space as a delimiter, e.g.
for items in a list
- in a LEIRI: valid. Processing to IRI: percent-encode
- in a URL5: invalid. Processing to URI: percent-encode
= U+003C, U+003E, '' U+0022, \ U+005C, ^ (U+005E), `
(U+0060), { (U+007B), | (U+007C), and } (U+007D): Delimiters and
Unwise characters
- in a URI: invalid, must be percent-encoded. Processing: stop
- in a IRI: invalid, must be percent-encoded. Processing: stop
Reason: Appendix C of [RFC3986] suggests the use of double-quotes
(http://example.com/;) and angle brackets (http://example.com/) as
delimiters for URIs in plain text. and Also, the fact that these
characters are not used in URIs or IRIs has encouraged their use
outside URIs or IRIs in contexts that may include URIs or IRIs.
- in a LEIRI: valid. Processing to IRI: percent-encode
- in a URL5: invalid. Processing to URI: percent-encode
Please note also that all references in this email are delimited by and
= % U+0025: Percent sign:
- in a URI: valid if followed by two characters in range [A-Fa-f0-9]
(hexadecimal digit). Processing: emit a percent-encoding token
- in a IRI: valid if followed by two characters in range [A-Fa-f0-9]
(hexadecimal digit). Processing: percent-decode if the char is allowed
without percent-encoding, else emit a percent-econding token.
Processing to URI: none
- in a LEIRI: valid if followed by two characters in range [A-Fa-f0-9]
(hexadecimal digit). Processing to IRI: none.
- in a URL5: valid if followed by two characters in range [A-Fa-f0-9]
(hexadecimal digit). Processing to URI: percent-encode
= : , / , ? , # , [ , ] , @, ! , $ , , ' , (
, ) , * , + , , , ; , =: Delimiters allowed in URIs
- in a URI: valid but have special meaning, else must be
percent-encoded. Processing: depends on scheme-specific syntax.
- in a IRI: valid but have special meaning, else must be
percent-encoded. Processing: depends on scheme-specific syntax.
- in a LEIRI: valid but have special meaning, else must be
percent-encoded. Processing to IRI: none
- in a URL5: valid but have special meaning, *cannot be
percent-encoded*. Processing to URI: ] , [ are automatically
percent-encoded after the host part, the rest is leaved as-is. # is
automatically percent-encoded in the fragment identifier.
= U+00A0-U+D7FF , U+F900-FDCF , U+FDF0-FFEF : Non-ASCII Unicode
- in a URI: invalid, must be percent-encoded. Processing: stop
- in a IRI: valid. Processing: none
- in a LEIRI: valid. Processing to IRI: none
- in a URL5: valid. Processing to URI: percent-encode
Re: [whatwg] Web Addresses vs Legacy Extended IRI (again)
2009/3/29 Anne van Kesteren ann...@opera.com: On Sun, 29 Mar 2009 14:37:19 +0200, Giovanni Campagna scampa.giova...@gmail.com wrote: Summing up, the differences between URL5 and LEIRI are only about the percent sign and its uses for delimiters. I'm not sure if you're correct about those differences, but even if you are they are not the only differences. E.g. LEIRIs perform normalization if the input encoding is non-Unicode. URLs do not. URLs can encode their query component per the input encoding (and do so for HTML and some APIs). LEIRIs cannot. What is the problem with normalization? Is there a standard for conversion to non-Unicode to Unicode? I guess no, so normalization (which should always be done) is perfectly legal. In addition, IRIs are defined as a sequence of Unicode codepoints. It does not matter how those codepoints are stored (ASCII, ISO-8859-1, UTF-8), only the Unicode version of them. This is the same as URL5s, by the way, because none of them is defined on octets and both use the RFC3986 method for percent-encoding (using UTF-8) (Also, I'm not sure if the WHATWG list is the right place to discuss this as the editor of the new draft might not read this list at all.) Unfortunately, I cannot join the public-html list. I could cross-post this to www-html or www-archive but it would break the archives and make it difficult to follow. -- Anne van Kesteren http://annevankesteren.nl/ Giovanni
Re: [whatwg] Web Addresses vs Legacy Extended IRI (again)
2009/3/29 Anne van Kesteren ann...@opera.com: On Sun, 29 Mar 2009 15:01:51 +0200, Giovanni Campagna scampa.giova...@gmail.com wrote: 2009/3/29 Anne van Kesteren ann...@opera.com: I'm not sure if you're correct about those differences, but even if you are they are not the only differences. E.g. LEIRIs perform normalization if the input encoding is non-Unicode. URLs do not. URLs can encode their query component per the input encoding (and do so for HTML and some APIs). LEIRIs cannot. What is the problem with normalization? Is there a standard for conversion to non-Unicode to Unicode? I guess no, so normalization (which should always be done) is perfectly legal. It's about Unicode Normalization. (And it should not always be done.) If I convert from ISO-8859-1 and find À (decimal 192), I can emit À U+00C0 LATIN CAPITAL A WITH GRAVE or A U+0041 LATIN CAPITAL LETTER A followed by ̀ U+0300 COMBINING GRAVE ACCENT One is NFC, the other is NFD, and both are legal and simple. In addition, IRIs are defined as a sequence of Unicode codepoints. It does not matter how those codepoints are stored (ASCII, ISO-8859-1, UTF-8), only the Unicode version of them. Please read the IRI specification again. Specifically section 3.1. Specification says that IRIs must be a in normalized UCS when created from user input, else it must be converted to Unicode if not already (and the conversion should be normalizing), else it must be converted from UTF-8 / 16 / 32 to UCS but not normalized. I don't see a particular problem in this. This is the same as URL5s, by the way, because none of them is defined on octets and both use the RFC3986 method for percent-encoding (using UTF-8) No, it's not always using UTF-8. RFC3986 never creates percent encoding (percent-encoding is used for unspecified binary data) but says that text components should be encoded as UTF-8 and that rules are estabilished by scheme specific syntaxes. -- Anne van Kesteren http://annevankesteren.nl/ Giovanni
Re: [whatwg] Web Addresses vs Legacy Extended IRI
2009/3/22 Ian Hickson i...@hixie.ch: On Sat, 21 Mar 2009, Giovanni Campagna wrote: Now I would like to ask: are there any major differences that requires the W3C / WHATWG to publish an other specification, just for HTML5, instead of just referencing the IRI-bis draft or the LEIRI working group note? As far as I can tell the LEIRI requirements aren't actually an accurate description of what browsers do. My question was more specific: what are the *techical differences* betwen LEIRI and Web Addresses? Can't we have one technology instead of two? Note that the Web addresses draft isn't specific to HTML5. It is intended to apply to any user agent that interacts with Web content, not just Web browsers and HTML. (That's why we took it out of HTML5.) Unfortunately, languages outside HTML5 (notably XLink, XML Base, SVG, XForms), that use W3C Schema definition and anyURI type, use exactly LEIRI. Other technologies instead use pure URI / IRI (XMLNS, RDF) and I wouldn't see much benefit in relaxing their syntax (because they never actually process their identifiers). -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Giovanni
[whatwg] Web Addresses vs Legacy Extended IRI
HTML5 originally included a section about resource identifiers processing. A few days ago that section was extracted into the W3C editor draft of Web Addresses. I noticed it and remembered that I had read once something like that. Precisely, what I once read is http://www.w3.org/TR/leiri, a note released by XML Core WG about legacy identifiers in XML content. This was later included into the IRI-bis draft, available at http://tools.ietf.org/html/draft-duerst-iri-bis-05 (section 7). Now I would like to ask: are there any major differences that requires the W3C / WHATWG to publish an other specification, just for HTML5, instead of just referencing the IRI-bis draft or the LEIRI working group note? Giovanni
Re: [whatwg] Accessing cookies from workers
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/9 Jonas Sicking jo...@sicking.cc:
On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
This can be even worse: how would you syncronize the code in the
callback with code right after the call? You don't have any of
semaphores or mutexes in ES and I don't expect them to be added soon.
I'm not sure I understand the problem you are describing. Could you
show an example using the APIs that exist in the spec today and with
an async cookie API added?
var x = 7;
function callback(cookies) {
x = 5;
}
getAllCookies(callback);
alert(x == 7);
True. The callback can't happen in the middle of executing code.
Javascript uses a run-to-completion model.
1) what does that mean?
The code in the callback is executed before reaching code outside
// doesn't seem very asyncronous
-or-
the code is executed after everything outside is already gone
// doesn't seem very useful, because code outside needs the result of
the cookie dependent routine
-or-
the code is executed in certain specific moments (when the thread is
waiting on a native call)
// doesn't seem very reliable, unless we specify what native call means
2) where is that specified?
I don't remember if the original Ecma262 has something about asyncronous calls
and most important
3) why it did actually happen in my code? (using an async XHR)
/ Jonas
Giovanni
@Drew:
If you don't want that workers set cookies in the middle of a JS block
in another browsing context, you just need to add a mutex at the
beginning of JS threads (timeout / intervals and event handlers), then
lock on that mutex in the setCookie.
This would make the call syncronous without problems for the JS developer.
Re: [whatwg] [html5] Rendering of interactive content
2009/2/11 Ian Hickson i...@hixie.ch
[...]
2) you depend on css3-ui, in CR stage, instead of becss, a very
early WD
BECSS is actually probably more stable than CSS3 UI at this point.
Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to
Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is
final, and waiting only for implementation.
CSS3 UI is very vague, and is going to need serious work before browsers
are able to actually implement it properly. A lot of the vendor feedback
at the time it was written was dismissed (e.g. it doesn't have a
particularly useful or comprehensive list of appearances).
Well, it is the *Basic* User Interface, that is, the bare minimum. All the
rest is Advanced UI, that I hope one day we will have.
3) you don't block the binding property: I don't expect that
applying an XBL binding on an element causes it to appear like a
span (because it gets almost no default CSS)
This is actually intentional. Experience with elements like fieldset
that have styles that aren't expressed in CSS is that you end up not
being able to restyle them properly if you desire. With 'binding' we'd
be able to knock out the whole default rendering (including weird
things with the children) in one go.
The fact is that binding it the best way to apply a set of event
handlers to an element. Having to tweak the computed style of a fieldset
in order to find what properties are actually set and reproduce them in
the binding, just to put a set of onchange handlers to lots of fieldset,
does not look optimal.
I don't understand why you would need to know what properties are set, or
what 'onchange' has to do with anything here.
html xmlns=http://www.w3.org/1999/xhtml;
head
xbl xmlns=http://www.w3.org/ns/xbl;
binding id=textboxes
handlershandler event=onchangewindow.alert(Hey! You changed my text
box!); /handler/handlers
/binding
/xbl
styleinput[type=text] { binding: url(#textboxes); }/style
/head
bodyforminput type=text value=Change me! //form/body
/html
At a first look, it just sets an onchange event handler to every
input[type=text]. Using the HTML5 approach to widgets presentation, you
would need to set the appearance to field on the bound element or it will
look much like a span
[...]
I mean that Firefox and Safari set the appearance property on the widget
element, and it is visible from outside, and dynamically changeable at
run time. The binding property instead contains an opaque and UA
specific value, that is not intended to be changed from JS (to switch
back and forth between widget types)
I expect we'll define actual values for 'binding' in due course; that's
mostly waiting on XBL2 getting implemented. I don't see why 'appearance'
would work better with JS than 'binding'.
Ah ok. I thought you wanted to leave that to be implementation dependent.
This is completely different.
[...]
We'll probably change that to just use keywords in due course.
So what should be the difference between appearance: field and binding:
field ?
[...]
It's a guide to Web browser vendors who wish to render things in a
commonly accepted way.
I think that section is for
- implementors of new UAs, that don't need to reverse engineer the
competitor products in order to find the defaults
Right.
- authors, that in this way know what to expect from the various UA with
less testing, that sometimes is also impossible, eg. you cannot test the
rendering of a mobile phone if you don't have a mobile phone
Having somewhere written that hyperlinks should be blue, allows you to
style
the background-color to anything but blue.
The section is not really for authors (though I suppose authors might find
it interesting, in the same way they might find the parser section
interesting).
[...]
Authors should act as if the default style sheet is something sensible but
they don't know what. (Because that is in fact what the situation is, once
you consider user style sheets.)
That is, the rule for authors is not just act as the UA default style sheet
was not present, but also act as if it was completely undefined or defined
to something weird, so explicitily write it every time it may be dangerous,
like for :link.
That's a completely different point of view. Thank you for clarifications,
I'll write div { display:block; } and :link { color:blue;
background-color:transparent;} in all my style sheets from now on.
Giovanni
Re: [whatwg] [html5] Rendering of interactive content
@Smylers:
So the whole rendering section is just for implementors and authors should
act if no default style sheet is present or worse, if it could be
everything, like a inline-block div or blue table, so that the author
should set all supported properties to initial or the HTML5 expected
value?
That is:
I, author, want consistent rendering on all plaforms and browser: I import
the HTML5 style sheet inside author ones.
I, implementor, want to provide backward-compatible rendering for those
author that didn't follow rule 1), I import HTML5 style sheet inside UA
defaults.
In both case, a downloadable stylesheet would be much appreciated.
@Benjamin:
1) Ian initially said that they chose the binding property (instead of
specifying appearance, border, color, etc.) in order to allow easy
resetting of default look-and-feel for widgets
2) I thought that author could make assumptions about the default CSS,
Smylers convinced me that this cannot be true
3) at least in that case I know that if web site doesn't work, it is not my
fault, but user's. But this has a major flaw:
customer is always right. In addition, once again, I was convinced that
you can't make assumption on UA rendering.
4)
input[type=text] {
border:1px solid blue;
font: Arial 10pt;
user-input: enabled;
user-modify: read-write;
cursor: url(I-beam.png);
}
looks different than
@appearance field {
border:1px solid ThreeDFace;
font:field;
user-input:enabled;
user-modify: read-write;
cursor: text;
}
@sys-color ThreeDFace rgb(0,0,255);
@sys-font field {
font-family: Arial;
font-size: 10pt;
}
@sys-cursor text {
src: url(I-beam.png);
}
input[type=text] {
appearance:field;
}
assuming three imaginary at-rules to define UA skin at CSS level.
5) I agree with you, it may be impossible
6) either HTML5 defines everything, or it defines nothing
Giovanni
Re: [whatwg] [html5] Rendering of interactive content
2009/2/9 Smylers smyl...@stripey.com Giovanni Campagna writes: So the whole rendering section is just for implementors and authors should act if no default style sheet is present No; the section is also for authors, in that it advises them of how content is expected to be rendered in mainstream graphical browsers. or worse, if it could be everything, like a inline-block div or blue table, Indeed it _could_ be anything, but there's no reason for authors to be worried about that; if a (non-malicious) user-agent does something different from that expected by HTML 5 then it presumably has done so intentionally and it wouldn't necessarily benefit users for authors to attempt to combat it. The fact is that could lead to mixtures (part of UA stylesheets and part of author style sheets) caused by the cascade mechanism that cannot integrate themselves. so that the author should set all supported properties to initial or the HTML5 expected value? Not necessarily. That is: I, author, want consistent rendering on all plaforms and browser: I think that's where you're going wrong. Platforms themselves aren't consistent -- in things like screen sizes, resolutions, distance between screen and audience, whether they are interactive, what input devices are available, pagination. From the same CSS, you cannot get different results in different browsers or platforms (unless the browser are not complying with CSS). Content may be scaled, wrapped, clipped, overflowed, but it will always be the same. A mobile browser should be different than a resized Firefox window. (Actually, IE in Windows Mobile / CE is like IE in Windows XP / Vista, just with a smaller viewport. The same applies for Safari in the iPhone or in Mac OS). In addition, you can have digital pens also in desktop PC, but you expect that your browser renders in the same way. If an esoteric platform chooses to divert from the expected HTML 5 rendering then it's likely because that platform knows more about what rendering is appropriate for that platform that you do. I'm not sure the UA knows better than me how to render my web site, because this would mean it knows how to render every website in the whole world, better than its own author. It may know better than me how to render specific parts of it (ie widgets), but not all of it. I import the HTML5 style sheet inside author ones. That's a very parochial view. In mainstream graphical browsers such importing would be redundant, because they'll have the expected behaviour anyway. Can I assume they'll have the expected behaviour? No I cannot, because HTML5 explictly says that UAs may render in every way they like. In esoteric user-agents you cannot know that the HTML 5 defaults provide a better user experience than those chosen by the user-agents' developers. But I can know that it cannot provide a worse user experience, because, as I said, given a CSS and a media type (screen - interactive - visual), the rendering is always the same. Maybe scaled, wrapped, overflowed, but always the same. (yellow is still yellow, overflow: scroll still produces scrolling mechanisms, display:table renders a table, width:auto is like width:100% in non-floated non-positioned block-level elements, etc.) I, implementor, want to provide backward-compatible rendering for those author that didn't follow rule 1), I import HTML5 style sheet inside UA defaults. In both case, a downloadable stylesheet would be much appreciated. I think a downloadable style-sheet is inevitable! Then let's wait for Ian to write one. Smylers Giovanni
Re: [whatwg] [html5] Rendering of interactive content
2009/2/8 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com
On 7/2/09 20:07, Giovanni Campagna wrote:
Yes, but what properties should I query for?
In order to find out what, precisely?
What to reset, for example (see the first Ian email on this topic)
Binding, behaviour, appearance, border, color, font, all in once? And
what should their values be?
Their values depend on user agent defaults (which may be anything), user
preferences (which may be anything), user stylesheets (which may be
anything), and publisher styles (which may be anything), as per the CSS
cascade:
I am the author, so at least those values are known. For what concern user
stylesheets, I should try to override them, it is the user that wants them.
So the only properties I may find useful to know the values are UA default,
that should be consistent across different platform and browser.
http://www.w3.org/TR/CSS21/cascade.html#cascade
In other words, the values cannot be known for sure until you query them.
Even if you mandated precise user agent defaults, the values still could
not be known for sure until you queried them, because of user preferences,
user stylesheets, and publisher styles.
If you mandate strict UA default, and the publisher (I repeat, I am the
author, I know what I write) overrides them, he may be sure that: either it
will look as no default style applied at all, or any additional property
that applies has been set by the user (so it is not my problem, he wanted
all the as to be purple on yellow background, even if it looks horrible to
me)
If input type=submit in some UA is rendered with all properties set
to initial, not only it does not express the semantic of a button, but
it may be difficult for a user to actually recognize it as a button and
eventually click it.
In that case I, as the author, may need to manually
set { appearance:push-button; content:attr(value,string,Send); } in
order to have my form submitted.
Try this example (in Firefox or Safari):
data:text/html,stylelabel { position:fixed; top:-1em; border:1px solid
black; } label input { -moz-appearance:none; -webkit-appearance:none;
border:none; width:auto; } input[type=submit] { -moz-appearance:none;
-webkit-appearance:none; background-color:transparent; border:none;
}/styleform action=http://www.google.com/search;
method=getlabelSearch: input type=text value=
name=q/labelinput type=submit value=Go
Imagine that was the UA default stylesheet instead of an author
stylesheet and you may see what interoperability means with web
application look and feel.
There's a recursion problem there.
User agents may derive the effects of appearance from user-agent default
stylesheets:
http://www.w3.org/TR/css3-ui/#appearance
UA must derive the appearance effects from the user agent skin, widgets
theme or native platform widgets (ie the common controls on win or the Gtk /
Qt themes in Linux). Those settings are not part of the UA default style
sheet, are not necessarily expressed in CSS, and do not take part in the
cascade.
If the user agent default stylesheet does not style push buttons
differently from other content, and the user agent derives the effects of
appearance from that stylesheet, then checking or setting the value of
appearance would not guarantee that your submit button would appear
button-like.
HTML5 should not mandate the UA present as in blue, but it should
mandate the UA present as like links (appearance:hyperlink).
How would you test whether a UA complied with that requirement or not?
Purely by testing the value of the appearance property applied to the
element with a default configuration?
1) you test the conformance to HTML5 by testing the value of appearance and
the semantics of the element (it must be an hyper-link, if you want
normative rendering or not)
2) you test the conformance to CSS3 UI by testing the look and feel of the
elements, and comparing it to the standard look and feel for that platform,
skin, them, etc.
Obviously this does not relate in any way with user preferences, here we
talk about UA defaults.
What if a developer wants to create a UA reflecting a target market's
differing preferences for presentation, rather than require the users to
configure it first?
Are you proposing such a UA should be non-conforming?
Could you propose an example of this UA, that still preserves the semantics
of the elements, as required by HTML5?
--
Benjamin Hawkes-Lewis
Giovanni
Re: [whatwg] [html5] Rendering of interactive content
2009/2/8 Smylers smyl...@stripey.com
Giovanni Campagna writes:
If input type=submit in some UA is rendered with all properties
set to initial, not only it does not express the semantic of a button,
but it may be difficult for a user to actually recognize it as a
button and eventually click it. In that case I, as the author, may
need to manually set { appearance:push-button;
content:attr(value,string,Send); } in order to have my form
submitted. Try this example (in Firefox or Safari):
data:text/html,stylelabel { position:fixed; top:-1em; border:1px
solid black; } label input { -moz-appearance:none;
-webkit-appearance:none; border:none; width:auto; } input[type=submit]
{ -moz-appearance:none; -webkit-appearance:none;
background-color:transparent; border:none; }/styleform
action=http://www.google.com/search; method=getlabelSearch:
input type=text value= name=q/labelinput type=submit
value=Go
Imagine that was the UA default stylesheet instead of an author
stylesheet and you may see what interoperability means with web
application look and feel.
Indeed it would be a problem if a major web browser shipped with such a
default style-sheet. But ... I'm really having trouble imagining any of
them doing so. It isn't in mainstream browsers' interests to produce
products which purposefully confuse their users.
Surely a browser which disguises buttons as plain text is going to lose
market share of its own accord, regardless of what HTML 5 says?
Or, to look at it from the opposite direction, supposing a browser
producer really wanted to make buttons look like plain text, would
whether HTML 5 condemns this practice really affect what they do? Would
not being able to market their browser as HTML-5-compliant be enough
that they'd begrudgingly forget their desire? Would users dissatisfied
with the behaviour only complain because it breaches HTML 5, rather than
because, say, it's really stupid?
I can't see how a requirement such as you propose would make any
practical difference on avoiding the outcomes you wish to avoid. But it
might unnecessarily curtail innovation in directions that we haven't yet
envisaged -- perhaps somebody developing a specialist user-agent for
mobile devices (or digital TV, or for print-based output, or
large-screen non-interactive displays, or ...) comes up with a different
way of displaying certainly elements which she considers is superior for
her particular target audience; why should the spec attempt to dissuade
her from doing so?
Smylers
I agree with you that we must not constrain the innovation, but in that
case, what is the whole purpose of the Rendering section?
I think that section is for
- implementors of new UAs, that don't need to reverse engineer the
competitor products in order to find the defaults
- authors, that in this way know what to expect from the various UA with
less testing, that sometimes is also impossible, eg. you cannot test the
rendering of a mobile phone if you don't have a mobile phone
Having somewhere written that hyperlinks should be blue, allows you to style
the background-color to anything but blue.
If the UA suddenly displays hyperlinks in green and I decided that my
background is green, the user will complain with me, not with the UA (and
will probably switch to a different website)
Having somewhere said that table should be rendered as CSS tables, allows
you to put a border-collapse for example. If table suddenly starts to be
displayed as an hierarchical tree, my site may be broken at once.
The solutions are two:
1) either provide a default style sheets only for author and say: you want
the usual rendering everywhere? import this. This means that the whole
Rendering sections should be moved to an Appendix and a separate
downloadable CSS file should be provided. In addition the presentational
hints become useless, since many of them cannot be expressed in terms of
CSS, and actually, all UA default style sheets are less important, because
most of time they will be overriden by author style sheets. Last, but not
least, you have to face an increased traffic to load an heavy CSS file just
for two or three display.
2) mandate a set of CSS properties and value.
Giovanni
Re: [whatwg] [html5] Rendering of interactive content
2009/2/6 Ian Hickson i...@hixie.ch On Fri, 6 Feb 2009, Giovanni Campagna wrote: I'm proposing to replace the current rendering mechanism, based on Behavioural Extension to CSS, that in turn is based on XBL2, with something based on the CSS3 Basic User Interface (css3-ui), ie replacing the binding: property with appropriate appearance: property directly on the element, instead of relying on the binding itself. The two properties are orthogonal -- 'binding' sets the behavior, 'appearance' sets the look-and-feel. I thought about it later, and I realized that you cannot style complex widgets without XBL (or something like that) because pseudo-elements are not reached by events. If they ever would, we would have horrible situations we have now. So for complex widgets (Number, File, Slider) it may be impossible to avoid a binding property, but anywhere it is possible you should try to use the available (appearance, content, icon, etc.). Even when using those, the author is able to shut them down, and knows perfectly which of them apply (they're defined normatively in HTML5 and they're exposed by browser tools for web dev). This allows for them to be selectively disabled, eg. to show BB without a button but with the native icon. What is more important, is that appearance normatively defines what properties from outside the appearance definition are allowed to interfere with the native look of the widget, binding does not. If author style sheets are not imported in XBL (apply-author-sheets=false), they don't apply at all. The advantage of appearance vs binding is that: 1) you don't need an additional pass before applying the correct platform-specific widget style With UA-native bindings, you wouldn't need an additional pass either. The current spec says User agents are encouraged to make their bindings set the 'appearance' CSS property appropriately to achieve platform-native appearances for widgets: this means that the binding should set appearance, and then appearance should make the widget look like a normal button. 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD BECSS is actually probably more stable than CSS3 UI at this point. Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is final, and waiting only for implementation. 3) you don't block the binding property: I don't expect that applying an XBL binding on an element causes it to appear like a span (because it gets almost no default CSS) This is actually intentional. Experience with elements like fieldset that have styles that aren't expressed in CSS is that you end up not being able to restyle them properly if you desire. With 'binding' we'd be able to knock out the whole default rendering (including weird things with the children) in one go. The fact is that binding it the best way to apply a set of event handlers to an element. Having to tweak the computed style of a fieldset in order to find what properties are actually set and reproduce them in the binding, just to put a set of onchange handlers to lots of fieldset, does not look optimal. 4) you keep the appearance property working: current UA (Firefox and Safari at least) already implement appearance, and correctly set it on the input element. This could no longer be possible using XBL, because of the CSS inheritance model inside XBL (if you apply to appearance to some part of the shadow tree, it is not visible on the bound element) I don't understand what you mean here. I mean that Firefox and Safari set the appearance property on the widget element, and it is visible from outside, and dynamically changeable at run time. The binding property instead contains an opaque and UA specific value, that is not intended to be changed from JS (to switch back and forth between widget types) 5) becss requires one or more binding languages: it is not necessarily XBL2, but currently XBL2 is the only one available: are you constraining the implementation of HTML5 on that of XBL2? The rendering section has no actual requirements in it, so nothing is constrained. Furthermore, nothing requires the binding language used by the UA to actually be a real language, so long as it is triggered by the 'binding' property. A number of elements have their rendering defined in terms of the 'binding' property (HTML5, with normative reference to BECSS) No BECSS -- no rendering -- no interoperability A user agent cannot comply to this specification without also supporting one or more binding languages such as XBL (BECSS, with informative reference to XBL2) Do you know any other binding languages outside XBL or HTC (that uses behaviour instead of binding)? *Computed Value:* specified value, with URIs resolved to absolute URIs When a specified URI cannot be used, e.g. due to network errors or because the specified binding
Re: [whatwg] [html5] Rendering of interactive content
2009/2/7 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com
On 7/2/09 14:22, Giovanni Campagna wrote:
5) becss requires one or more binding languages: it is not
necessarily
XBL2, but currently XBL2 is the only one available: are you
constraining
the implementation of HTML5 on that of XBL2?
The rendering section has no actual requirements in it, so nothing is
constrained. Furthermore, nothing requires the binding language used by
the UA to actually be a real language, so long as it is triggered by
the
'binding' property.
A number of elements have their rendering defined in terms of the
'binding' property (HTML5, with normative reference to BECSS)
No BECSS -- no rendering -- no interoperability
The introduction to the rendering section says:
'User agents are not required present HTML documents in any particular way.
However, this section provides a set of suggestions for rendering HTML
documents that, if followed, are likely to lead to a user experience that
closely resembles the experience intended by the documents' authors. So as
to avoid confusion regarding the normativity of this section, RFC2119 terms
have not been used. Instead, the term expected is used to indicate
behavior that will lead to this experience.'
http://www.whatwg.org/specs/web-apps/current-work/#rendering
So the rendering section imposes *no* requirements on HTML5 conforming user
agents, therefore the spec is not constraining the implementation of HTML5
on that of XBL2.
Yes, but UA that don't follow that set of CSS rules are not interoperable
with UA that follow, ie scripts must detect what properties are ignored or
defaulted.
Furthermore, user agents are free to use any method they like to mimic the
suggested rendering, including CSS3 UI where applicable. They don't have to
use BE CSS at all.
They're expected to use CSS, and I expect that, according to html5,
button { binding: initial; } makes it like a span.
If this is not obvious from the text, perhaps you would like to suggest a
change to the text that would make it clearer?
I don't agree with rendering being optional. If interoperability is so
important (and it is), rendering should be normative. Obviously I'm not
asking to depend on CSS, I'm asking that UA should act if the following CSS
was specified (even if it doesn't support CSS)
--
Benjamin Hawkes-Lewis
Re: [whatwg] [html5] Rendering of interactive content
2009/2/7 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com
On 7/2/09 18:51, Giovanni Campagna wrote:
So the rendering section imposes *no* requirements on HTML5
conforming user agents, therefore the spec is not constraining the
implementation of HTML5 on that of XBL2.
Yes, but UA that don't follow that set of CSS rules are not
interoperable with UA that follow, ie scripts must detect what
properties are ignored or defaulted.
HTML5 conforming UAs do not have to implement CSS or CSSOM.
CSSOM-implementing UAs do not have to do express all styling with CSS
properties.
When they do, you can query for those properties via the CSSOM.
Yes, but what properties should I query for? Binding, behaviour, appearance,
border, color, font, all in once? And what should their values be?
Furthermore, user agents are free to use any method they like to
mimic the suggested rendering, including CSS3 UI where applicable.
They don't have to use BE CSS at all.
They're expected to use CSS, and I expect that, according to html5,
button { binding: initial; } makes it like a span.
Is text I quoted not clear that the word expected is chosen precisely to
make it clear that these are _not_ normative requirements? If so, could you
suggest modifications to the text to make it even clearer?
If this is not obvious from the text, perhaps you would like to
suggest a change to the text that would make it clearer?
I don't agree with rendering being optional. If interoperability is so
important (and it is), rendering should be normative.
How does that follow?
If input type=submit in some UA is rendered with all properties set to
initial, not only it does not express the semantic of a button, but it may
be difficult for a user to actually recognize it as a button and eventually
click it. In that case I, as the author, may need to manually set {
appearance:push-button; content:attr(value,string,Send); } in order to
have my form submitted.
Try this example (in Firefox or Safari):
data:text/html,stylelabel { position:fixed; top:-1em; border:1px solid
black; } label input { -moz-appearance:none; -webkit-appearance:none;
border:none; width:auto; } input[type=submit] { -moz-appearance:none;
-webkit-appearance:none; background-color:transparent; border:none;
}/styleform action=http://www.google.com/search;
method=getlabelSearch: input type=text value=
name=q/labelinput type=submit value=Go
Imagine that was the UA default stylesheet instead of an author stylesheet
and you may see what interoperability means with web application look and
feel.
And what do you mean by rendering should be normative?
Are you suggesting, for example, that HTML5 should mandate unvisited links
be blue and underlined in the screen medium unless set otherwise by a
publisher stylesheet? That would prevent UAs providing a default
presentation of semantic HTML that suits the end-user!
Note that would prevent UAs complying with W3C's user-agent accessibility
guidelines:
http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles
HTML5 should not mandate the UA present as in blue, but it should mandate
the UA present as like links (appearance:hyperlink). The color of course
is a matter of visual themes and platform.
An other example: HTML5 should mandate button displayed with
appearance:push-button; even if the UA doesn't support CSS.
Also compare it to the normative style sheet for XHTML2 [1]: it does not
require CSS, but it does require that some look and feel (very basic
actually) is enforced to express the semantics of elements.
Obviously this does not relate in any way with user preferences, here we
talk about UA defaults.
--
Benjamin Hawkes-Lewis
Giovanni
[1] http://www.w3.org/TR/xhtml2/xhtml2-style.html#a_stylesheet
[whatwg] [html5] Rendering of interactive content
I'm proposing to replace the current rendering mechanism, based on
Behavioural Extension to CSS, that in turn is based on XBL2, with something
based on the CSS3 Basic User Interface (css3-ui), ie replacing the binding:
property with appropriate appearance: property directly on the element,
instead of relying on the binding itself.
This in particular applies to the button, input, select and textarea.
Something like this could be included:
button,input[type=submit],input[type=button],input[type=reset] {
appearance:push-button;
}
input[type=submit],input[type=button],input[type=reset] {
content:attr(value,string,contents);
}
input {
appearance:field;
border-width: calc(attr(size,px,0) / 2); /* presentational hint */
}
input[type=password] {
appearance:password;
}
input[type=url]::outside::after {
appearance:push-button;
content:icon;
icon: url(icon uri);
} /* the current appearance in Opera */
input[type=range] {
appearance:range; /* Webkit uses a proprietary -webkit-slider-horizontal for
this */
}
input[type=checkbox] {
appearance:checkbox;
}
input[type=radio] {
appearance:radiobutton;
}
input[type=file]::outside::after {
appearance:push-button;
content: Browse...;
}
select[size] {
appearance:list-menu;
}
select,select[size=1] {
appearance:pop-up-menu;
}
The advantage of appearance vs binding is that:
1) you don't need an additional pass before applying the correct
platform-specific widget style
2) you depend on css3-ui, in CR stage, instead of becss, a very early WD
3) you don't block the binding property: I don't expect that applying an XBL
binding on an element causes it to appear like a span (because it gets
almost no default CSS)
4) you keep the appearance property working: current UA (Firefox and Safari
at least) already implement appearance, and correctly set it on the input
element. This could no longer be possible using XBL, because of the CSS
inheritance model inside XBL (if you apply to appearance to some part of the
shadow tree, it is not visible on the bound element)
5) becss requires one or more binding languages: it is not necessarily
XBL2, but currently XBL2 is the only one available: are you constraining the
implementation of HTML5 on that of XBL2?
~ o ~
A part from that, I would like to propose the following CSS for some missing
parts:
marquee[behaviour=slide] {
marquee-style:slide;
}
marquee[behaviour=scroll] {
marquee-style:scroll;
}
marquee[behaviour=alternate] {
marquee-style:slide;
}
marquee[direction=left] {
marquee-direction:forward;
overflow-style:marquee-line;
}
marquee[direction=right] {
marquee-direction:backward;
overflow-style:marquee-line;
}
marquee[direction=up] {
marquee-direction:backward;
overflow-style:marquee-block;
}
marquee[direction=down] {
marquee-direction:forward;
overflow-style:marquee-block;
}
marquee[loop] {
marquee-play-count: attr(loop,integer,initial);
}
(This obviously means that we need a definition of marquee accepting
attributes behaviour = (slide | scroll | alternate), direction = (left |
right | up | down), loop = integer. Info found from MSDN).
progress {
display:block;
content:none;
background-color:green;
width: calc(1% * attr(value,number,0) / attr(max,number,1) );
}
progress::outside {
display:block;
text-align:center;
width:auto;
content:contents;
}
progress:empty::outside {
content:calc(attr(value,number,0) / attr(max,number,1) * 100) %;
}
The same could apply for meter as well, except for the handling of optimal
and suboptimal parts.
menu[type=toolbar] {
appearance:menu-bar; /* are menu bars visually different from tool bars? */
}
menu[type=context]:active {
appearance:menu;
display:block; /* may be actually implied by appearance:menu */
}
menu[type=toolbar] menu::outside::before, menu[type=toolbar]
select::outside::before, menu[type=toolbar] menu::outside::after,
menu[type=toolbar] select::outside::after, menu[type=toolbar] hr,
menu[type=toolbar] option[value=]:disabled, menu[type=context]
menu::outside::before, menu[type=context] select::outside::before,
menu[type=toolbar] menu::outside::after, menu[type=toolbar]
select::outside::after, menu[type=context] hr, menu[type=context]
option[value=]:disabled { /* separators */
display:block;
content:;
border: 1px solid ThreeDFace;
width:0px;
}
menu[type=toolbar] menu[label], menu[type=toolbar] optgroup[label],
menu[type=context] menu[label], menu[type=context] optgroup[label] {
appearance:pull-down-menu; /* actually, where are we supposed to specify the
label? */
}
menu[type=toolbar] a, menu[type=toolbar] button, menu[type=toolbar]
input[type=submit], menu[type=toolbar] input[type=reset], menu[type=toolbar]
input[type=button], menu[type=toolbar] input[type=checkbox],
menu[type=toolbar] input[type=radio], menu[type=toolbar] select option,
menu[type=toolbar] command, menu[type=toolbar] bb, menu[type=context] a,
menu[type=context] button, menu[type=context] input[type=submit],
menu[type=context] input[type=reset], menu[type=context] input[type=button],
menu[type=context]
Re: [whatwg] 5.12.3.7 Link type help
a elements are always hyperlinks, link can be hyperlinks or resources. So it only makes sense for the link element to be explicitly marked like this. Giovanni 2009/2/3 Philipp Kempgen philipp.kemp...@amooma.de: ---cut--- 5.12.3.7 Link type help The help keyword may be used with link, a, and area elements. For link elements, it creates a hyperlink. ---cut--- Shouldn't that read For *a* elements, it creates a hyperlink.? Philipp Kempgen -- AMOOCON 2009, May 4-5, Rostock / Germany - http://www.amoocon.de Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --
Re: [whatwg] Trying to work out the problems solved by RDFa
I've tried to follow all the discussion besides of its lengths and my conclusion is: You're asking the wrong question People against RDFa in HTML5 are asking why do you need RDFa?, and supporters of the proposal are actually describing the benefits of RDFa itself. The right question is: why do you need RDFa *inside HTML5*? My personal answer to this question is: There is no needing for RDFa inside HTML5. There are other markup languages which support RDFa natively (XHTML for example). You may say that in this way you help to divide the web in two sides, users of HTML5 and users of XHTML2. Actually the web, is already divided in two big groups: - Web of data - Web of interaction Web of data means all the page whose primary objective is to provide some information, either user-readable or machine-readable to the users, while web of interaction include web application, whose primary purpose is to provide additional services to the users. These two groups have very different requirements (GMail doesn't need RDFa in application code, while Wikipedia doesn't need a progress element), so specific markup languages may suit better the web site. Moreover, this distinction is not a requirement, is just an advice: you can put metadata inside HTML5 using Microformats and you can put interactivity inside XHTML2 using XMLEvents. Summing up: if you author feel the absolute needing for metadata, because delivering content to the users is your primary goal, then switch from HTML5 to something else, and leave HTML5 to web application, focused on user interaction. Giovanni
Re: [whatwg] Spellchecking mark III
2008/12/30 timeless timel...@gmail.com On Tue, Dec 30, 2008 at 5:20 PM, Kornel Lesiński kor...@geekhood.net wrote: It's useful for fields that contain non-textual content, e.g. product ID, license plate number, CAPTCHA answer, etc. Browser would mark these as misspelt, which might be confusing or at least distracting. this sounds like something browser vendors need to worry about on their own and is not a reason to let web pages do anything about it. maybe we could just say that spellchecking is disabled when type is not text (for email, uri and number you have validation) and when a pattern attribute is specified Giovanni
[whatwg] (X)HTML + SMIL?
Very back in 2002, a W3C Note about the integration of XHTML (at that time was 1.1, now it would be 2.0) and SMIL (at that time 2.0, now 3.0). I was wondering if any work was produced because of that document, or it was simply forgotten. IMHO, it addresses many issues: 1) the video HTML5 element can be replaced by SMIL video into XHTML2 documents, alongside with the SMIL DOM, quite similar to HTML5 media DOM. It also solves accessibility problems such as how to put subtitles into video (use the SMIL Text Module) 2) CSS Transitions, that currently are WebKit propietary extensions, can be implemented using SMIL Animation Module. What is more important, many browsers already implement SMIL Animations on SVG elements, so they could easilily port them to XHTML2 (or 5 if they prefer) I hope that some work has been done and I'd like answers about that Giovanni
[whatwg] Merry Christmas!
Probably you didn't notice, but it is 25th December today. Merry Christmas and Happy New Year to all members of WHAT and W3C working groups! Giovanni
Re: [whatwg] Parsing, syntax, and content model feedback
2008/12/25 Ian Hickson i...@hixie.ch We're very constrained by the legacy for text/html's syntax; sadly, usability concerns aren't really able to make us change the language. [...] The goal is not to guess what the author meant when the authors makes a mistake; the goal is to have interoperable, predictable, defined behavior for all input. [...] See below Could you elaborate on how spec design like XHTML modularisation has any impact on developers of Web applications? I was under the impression that the only benefit was in the development of other specs based on the modules (and that only if those needs happened to mesh with the particular modules picked). Because of XHTML Modularization, I can build a XML Schema of different markup languages, integrate and validate them, without overlapping or redundance. Yes, DTDs are not dead, just they're not used in browsers. I assume you mean in forms? 1) use XMLSchema datatypes It's unclear how XML Schema datatypes would work with HTML forms and how they would be better than what we have in forms in HTML5 now. XForms use XMLSchema datatypes (default or user-defined). Btw, I meant the first part of HTML5 spec (parsing of date - time - numbers - etc.) 2) additional DOM interfaces, which include HTMLElement - HTMLCollection - HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList - DOMStringMap 2) you don't need HTMLElement: markup insertion, attributes querying can be done using DOM3Core (that in latest browser are even more performant as no parser is involved), events are far better handled by DOM3Events, styling is included by CSSOM you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 Both HTMLElement and collections are in DOM2 HTML (even DOM1 HTML). DOMStringMap is basically nothing but a binding-specific feature. I don't see your point XHTML2 is not backwards compatible, and was a big part of the motivation behind starting the HTML5 effort. Still, see below. Extensibility is an anti-feature -- we specifically don't _want_ people to extend HTML without working with the wider community. That way lies fragmentation of the language and lack of interoperability. Indeed, what little non-centralised extension HTML has seen -- spacer, blink, marquee -- has been widely decried as a disaster. XMLHttpRequest was invented by Netscape, now it is a W3C Technical Report (I don't remember what maturity level). The same with so called DOM level 0 (now HTML5) Extensibility doesn't mean proprietary extensions: it means that organizations other than WHATWG can collaborate and you are sure that they're extension don't break existing specifications. Also this affects new versions of current module: for sure XForms 1.1 or XMLEvents 2, when they'll be finished, won't break XHTML Structural or Embedded Attributes Module. structure, sectioning, grouping are the same; It's unclear why you think XHTML2's features in this area are better than HTML5's. Can you elaborate? are the same means that literally there is no difference between XHTML2 and HTML5 about structure, sectioning and grouping of text text is very similar: you don't have time, but you can have span datatype=xsd:date content=2008-12-21Today/span as in HTML5 you have time value=2008-12-21Today/time; Why is that better? It seems far worse. Because you can have date, but you can have email, phone number, zip postalcode, that is any data that have specific formats. Or if you are focused on semantic you use property instead of datatype, and you can put there whatever you feel like, not just times, progresses or range values. for progress and meter semantic you can use role attribute (for styling you always use CSS); That would have a terrible accessibility story as far as I can tell. Why? Implementations will look for elements with role=progress (imaginary) instead of progress element, and they will read/display/print/whatever the content attribute (same as time) or element's content. A part from performance, what is the difference between: document.getElementsByTagName(progress) and document.querySelectorsAll([role=progress]) or document.evaluate([...@role=progress]); (not sure about XPath syntax, btw) when searching for progress elements to get their semantics? The same obviosly with any element This is an area where we are mostly just constrained by legacy -- ins amd del are from HTML4, not new in HTML5. See below embedding is much more powerful as any element can be replaced by embedded content; This isn't more powerful, it's more buggy. Just compare object with img. Making things general is something that language designers often feel is a good way to solve many problem at once, but usually it just ends up not solving any of the problems
Re: [whatwg] Thoughts on HTML 5
2008/12/21 Garrett Smith dhtmlkitc...@gmail.com Styling is done in css. Dynamic styling is currently done with the style property of HTMLElement. This is currently implemented in DOM2HTML and HTML5, but I once read they're going to write a separate CSS-Object Model, whose spec is not ready yet, but it is mentioned in the CSS current work. I don't have time to go into the all the problems with CSSOM here. Shortcomings of the CSSOM 'views' module were discussed on www-style. 'VIews' is not the only CSSOM module that has problems. Most of CSS is already implemented (like HTML, they're just standarizing what browser already do) you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 Where are you getting this information? What information? a) DOMNodeList are collection of ordered Nodes -- see DOM3Core for definition - if you want only Element Nodes see the Element Traversal specification by the WebApps WG b) ECMAScript Object are implemented as associative arrays (hash map / binary tree) -- see Mozilla Developer Center: it is only about Firefox, but I think all browser behave like this since they must reference arbitrary properties that are not known at compile time (if they compile) c) DOMStringMap is defined to be like ECMAScript Object -- look at its IDL: it has no members, no properties, no methods but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) The closest definition to 'nothing' would be the value undefined. I do not know of a browser where - window.window.window === undefined is true by default. I get window. a) undefined != undefined is true in ECMAScript b) i didn't mean undefined, i mean literally nothing, eg this script window.window.window.window.window.window.window.alert(hello, world); is exactly the same as alert(hello, world); The closes thing we got to an example of invalid html is TJ post about jquery validation plugin. If you click throuh, there is an demo using a minlength custom attribute. The attribute may have the effect the author wanted it to have in a set of browses he is concerned about. That effect and the set of browsers could be more clearly demonstrated in an example that shows only that, as well as edge cases where results may vary. I don't see your point... If you can't define clearly what can be reasonably expected of a piece of (invalid) code, then nothing can be reasonably expected of it. It's not a good to write code that can't have an expected outcome. HTML5 is here to define what browser must and must not do with de-facto standards (called DOM Level 0, but also features that once were browser-specific like embed) Instead what I'm asking is only for the developer point of view. Giovanni
Re: [whatwg] Thoughts on HTML 5
Please Note: all the following is my personal humble opinion. As I discovered lately, the main problem of HTML5 is its design oriented to keep features that are distributed across browsers, that work or that are simple way to solve big problem. Actually, they are a bunch of different features somehow not integrated to the others. Instead, programmer (please note, I use the word programmer, not author or web designer) developing *new* application may more like a more structured and logical organization, like XHTML modularization is. HTML5 features, summed in big groups, are (in spec order): 1) common syntax for the most used datatypes. 2) additional DOM interfaces, which include HTMLElement - HTMLCollection - HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList - DOMStringMap 3) Elements and Content Models 4) Element types: metadata - structure - sectioning - grouping - text - editing - embedding - table - forms - interactive - scripting elements 5) User agent requirements 6) User Interaction 7) Communication 8) HTML Syntax Some of these features can be achieved without any of HTML5, for example 1) use XMLSchema datatypes 2) you don't need HTMLElement: markup insertion, attributes querying can be done using DOM3Core (that in latest browser are even more performant as no parser is involved), events are far better handled by DOM3Events, styling is included by CSSOM you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 3) use XHTML2, which is extensible because modularized 4) metadata is better handled by XHTML2 Meta Attributes module, which fully integrates the RDF module in any elements; structure, sectioning, grouping are the same; text is very similar: you don't have time, but you can have span datatype=xsd:date content=2008-12-21Today/span as in HTML5 you have time value=2008-12-21Today/time; for progress and meter semantic you can use role attribute (for styling you always use CSS); editing is the same, but you have an attribute instead of an element, so you don't have the issue that ins and del can contain everything, even a whole document (not including html); embedding is much more powerful as any element can be replaced by embedded content; tables are the same (you don't have tables API; but you can still use DOM3Core); XForms are actually more powerful than WebForms2, since you divide presentation from data from action (that is implemented declaratively); interactive elements are not needed at all: details is better implemented as it is now (ECMAScript3 + CSS3), datagrid is just a way to put data in a tree model: use plain XML for that; command and a in XHTML2 implemented in any element using href attribute; menu is mostly an ul with some style; scripting uses XMLEvents and handler: it looks the same, but it is different as it is more event oriented (scripts are not executed by default, they're executed when some event fires) 8) HTML syntax: as I said before, use XML for that There are instead features that are indeed very useful to develop a web application, but are not achievable using other means that HTML5: 1) some way to interact with object (please note: object, not embed: object is for plugins, embed for content) : actually this can be done using something like cross document messaging, assuming that object creates a new browsing context (it already does if the target is text/html or application/xhtml+xml), but we need a specification for message syntax 2) the binding specific global scope (that is, what object are available in all scopes, if binding supports this); this is normally the window object, but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) 3) the Window object (which includes window name, window location, cross document messaging, dialog windows) 4) Protocol and Content Handlers 5) Session and Local storage 6) Database storage 7) Drag and Drop 8) WebSockets What I am asking now is so to modularize HTML. copy those features into separate, interoperable modules, removing legacy features (like window.on-whatever event listener) A copy of those will remain in HTML5, because browser implement them at the moment, and the HTML5 goal is that all browser implement the same things in the same ways Instead, some web developers in the future will think that a modularized and less redudant API is more usable, like I personally do, and switch to that, without mixing with HTML5: actually, I guess what a Database API does inside HTML. Best regards, Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/17 Ian Hickson i...@hixie.ch This doesn't cost any time in HTML either, since the tokeniser doesn't need to worry about what tags have end tags, the tree construction side just drops unexpected end tags on the floor. I don't think authors expect tags to disappear. don't check for insertion modes Having an insertion mode isn't particularly a performance cost. (It affects code footprint, but that's about it.) 1) it needs more code (one x insertion mode): more code is always less performance, even if it is just to load a bigger executable 2) it needs code to select the insertion mode for the next element (when the spec says to reset the insertion mode): in the worst case it has to compare nodeName 18 times That's the same as HTML. No it is not. HTML defines special beaviour for the following elements: address, area, article, aside, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, command, datagrid, dd, details, dialog, dir, div, dl, dt, embed, eventsource fieldset, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hr, iframe, img, input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p, param, plaintext, pre, script, section, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, ul, and wbr. I think they're quite too many to say that it is like XML There are a number of HTML5 parser implementations, and data suggests that there is no particular performance gain. There are no actual HTML5 parser implementation, only HTML4 compatible with new syntax. (are you sure that closed source browsers really do what is written in the specification?) There's no guessing in HTML either; all input streams have very specific and required results. Actually, there's nothing that really says that divpsome text/ppsome more text/p/div is more correct than divpsome textpsome more text/p/p/div Just when writing the specification you guess that the first possibility is what auctor thought. You are guessing, not the browser. Validating code is certainly an important QA point, but once you've shipped code, the presence of an error is not helpful to the end user. Often errors in XML files weren't present when the file was created, but appear later when new text is merged in automatically. As Nils pointed, it is an error itself to have any content to be automatically merged inside a stream. It is like opening a random file, executing it and expecting no errors. Every input, even from the most trustworthy source, must be parsed for errors and then checked after publishing. And if an end user finds an error, he probably will report it to the owner of the web site, who in turn will report it (quite angrily) to web designer. Something like: What on earth are you doing in front of the coffe machine? I don't pay you to rest! Fix that website immediately! Well, they've ignored it for the past 7 years, so why would they change? Nobody said to user that he was browsing a deprecate web site. If something like IE7 information bar (ie. a non modal bar, disactivable and not annoying the user, but immediately visible) could appear in a web site sent with text/html, I think companies won't like their site tagged as deprecate and port them to application/xhtml+xml in no time (do you imagine what deprecate can mean on news web site?) And don't forget that the most common browser was IE6, not very standard oriented... Anyway, it isn't clear that we would _want_ to deprecate HTML, even if we had any real choice in the matter. I'm not sure if I understood your sentence (sorry, English is not my mother language). Anyway, you just have to put an authoring requirement for text/html 1) user agent will just ignore it and implement the HTML algorithm (we don't want to break the web, using Microsoft terms) 2) standard-oriented authors will convert their sites to application/xhtml+xml (if they didn't before) 3) other authors will keep their tag soup (and get their sites yellow-barred) 4) company owners will make their decision between 2 and 3 Gradually, n° 3 will disappear, because there's no actual needing for HTML. @ Garret: originally I wrote XBL2, then I deleted it since it was not pertinent (and went in opposite direction as my opinion), but i forgot to edit list number. Secondly, what do you mean with bubbling? Ok, I can put an event handler on what I need on, say, HTML, but then how can I execute the proper handler? I must retrieve it, either attaching it to the DOM node (but I don't advice it, it is not interoperable) or maintaing an hash map with class names / function pointers and solve it. Actually, there is no performant and clean solution, just few hacks.
Re: [whatwg] Thoughts on HTML 5
2008/12/18 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com Perhaps (got any actual evidence about author expectations in this case?), but that's not a problem for tokenizer performance. You're shifting the goalposts. My comment about tokenizer performance was later. By the way, author should not expect that invalid markup work in any particular way (in the past they did and wrote specific markup for specific implementation) Anyway, if we're talking authorial expectations, ordinary authors don't expect a href=http://example.com?foobarbaz; to be an unrecoverable error, but it is in XHTML. authors didn't expect that example.com?foobarsection=1 became example.com?foobar§ion=1 but this happened in Netscape and IE quite long ago if they got an error, at least they knew that it was not a correct syntax and should have been avoided, since it could lead to different results in different browsers (it is not valid HTML, btw) It's not like either of these syntaxes make sense to ordinary people or were even intended to do so. The original authoring model for HTML was supposed to be paragraph and anchor, mediated by some sort of vaguely WYSIWYG type editor, not angle-bracketed tags. If you don't like like less-than and greater-than (it is not Unicode angle bracket actually), publish your work in PDF or DOC. HTML stays for HyperText Markup Language. Markup (i.e. tags) can't be removed. A conforming browser will interpret the markup as specified by the specification, so there is no difference. Yes, the fact is that the specification itself guesses what an average author thinks when it writes HTML In practice, people find this very hard for XML and most web publishing systems (WordPress etc.) don't work like this even if they should. Why do SQL injections or buffer overrun attacks happen? Because applications don't check for input. The same for XML: you check, you're sure nobody will try to take your site down. You don't check, that's your fault. Also, much of the web is ad-supported. The ads ecosystem is based around including markup from trusted sources. Those including the markup are generally not able to exert much control over the included markup, even when they are some of the biggest publishers on the web. Getting ads to have user-friendly HTML (e.g. alt attributes for image links) is nigh impossible; trying to get conforming HTML is a wet dream; and trying to get ads in valid XML is a likely to be a complete non-starter. Why would an ad creator bother, when they could choose a different partner and use their old text/html ads? If ad buyer refuses to buy a non-valid-XML ad, probably the ad creator will rewrite them. Probably - got any empirical evidence for that? I don't usually report errors in websites I visit (even _I_ usually have other things to do with my time). If any error prevents someone from correctly browsing that page, he first reports that to web owner, then to browser creator. Indeed, they would be upset. And they might even try porting it. However, there's little incentive for browser makers to throw information bars over the majority of the existing web just to assuage your desire for people to switch to XML. In fact, there are disincentives for browser vendors to include such an information bar since: 1. Users will complain about error messages about sites that have always worked just fine. (I'm switching back to IE8.) 2. Users will be trained to ignore error messages since sites work just fine even with a finger-wagging information bar slapped across the top, which is a security risk. Even persuading browser vendors to include an indication of whether a website is valid or not has been a non-starter for every browser except iCab - and even iCab has dropped that indication in the latest version. If an user complains about a warning (not error) indication, he can disable it (but not security errrors). On the other hand, some user will complain with the site creator, instead of with the browser creator. Ian was effectively asking: Why deprecate text/html? You appear to be trying to answer: How would we deprecate text/html? which is a different question (and I've indicated some problems with your suggestion above). Sorry, I didn't understand (it looked like we want to deprecate html but we don't have instruments, but it didn't make much sense). Except on the ad-supported web… 1) use iframe 2) use object 3) use embed 4) use img 5) use well-formed XHTML 6) use JS + DOM Do you think it is enough? Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Ian Hickson i...@hixie.ch I tried following this thread but I can't find what I would need to change in the spec to address the feedback so far. If this feedback relates to requests for the spec, please elaborate on exactly what it is that should change -- thanks! I thought later on this topic and i arrived to conclusion that we cannot forbid or delete completely the HTML serialization, but there are no real use cases for this in server generated web pages. Even in case of user-generated content an application must parse it server-side prior to publish, and in the worst case may use the spec's algorithm to build a standard-compliant DOM tree, then serialize it producing valid XML code (therefore an application can always provid valid XHTML) In my opinion, we should allow content to be sent as text/html, but HTML serialization and associated technologies (DOMDocument.write or DOMElement.outerHTML) should be marked deprecate, since there are stricter and more performant way to do same thing. Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/17 Ian Hickson i...@hixie.ch XML is neither more performant nor stricter than XML. The main differences are that XML has less user-friendly error recovery and supports arbitrary namespaces. Authors have clearly indicated that this is not compelling. Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I don't write browser code, honestly, but I think that XML parser don't need to check for attribute types (they're all quoted strings), don't check for element type (whether there can or must be closing tag), don't check for insertion modes, just parses the input completely any semantic or particular behaviour associated with any tag. Then, when the DOMElement or DOMAttr or DOM-whatever are built, they get the appropriate interface (eg. HTMLElement) depending on the namespace. I think that the latter algorithm can be faster, but I actually haven't got any benchmark (I cannot have, since no browser implements completely HTML5 parse algorithm yet). Secondly, stricter to me means: every warning is an error. Look in the following code: divpsome text/div When the HTML parser find char 'd', i can imagine it expects char 'p' (as in /p) and fallback to quirk mode otherwise, although no assertion are made in the official HTML spec. When parsing as XML, though, the parser can simply get the char: is it a 'p'? then go forward, else stop parsing no quirks, no trying to guess author intentions what about divpsome textpsome more text/div? is it this: divpsome text/ppsome more text/p/div or either this: divpsome textpsome more text/p/p/div And most of time strict checking means less errors caused by distraction (misspelling of an end tag, missing '/' when self-closing elements not always selfclosing, etc.) Lastly, you said that deprecating HTML is vain. Well, IMO, if you deprecate it now, maybe this year, or next year, or even the year after, nothing will move. But (according to WHATWG Wiki) HTML spec will be ready in 2020. Do you think that in 12 years everybody will just ignore the string HTML is deprecated and should no longer be used? By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were independent specifications. Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna: (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Since data attributes do not exist as of yet, I believe people would use XML for namespaces, so I somehow don't see your problem. 1) data attributes are not standarized and the dataset DOMStringMap is not present, but if you try using them with domCore interfaces they should work (i haven't tested though) 2) XML serialization is much more difficlut to implement than old HTML, and, as i said before, in many cases it is not implementable at all: probably a company which hosts user-generated content such as blogs or forums won't like that no browser can display his pages because someone wrote invalid html even the most experienced can mis-type code, and in that case the only way to solve is to manually edit source using a plain text editor, which is not possible with user-generated content 3) the dataset DOMStringMap is a quite useful way to enumerate attributes explicitly marked as application data
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna: Browser assume that author knows XML because he's put an application/* +xml mime type. On the other hand, this assumption cannot be done for blogger, who aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not expected to know about what or w3c either) Then they shouldn't write XHTML in the first place ... there *are* some good autoformatters which handle stuff for you (think: newline - br/, two newlines - paragraph). Also, WYSIWYG editors should *not* gave you the oppontuniy to mess up your code. In a forum you usually write BBCode (or similar), that is server-side parsed with the same hacks as the HTML5 parser, while in other context it is definitely more powerful to write directly HTML Secondly, this: pClick on my icon a href=somewhere.htmlimg width=88 height=15 src=myicon.png/p is valid HTML although not valid XHTML. Do you mean this with messing up your code? Could not save you post, invalid XML markup (Mismatched end tag, expecting img, found /p) See W3C XML1.1 specification (link to XML spec) for further information about this. Or just Not well-formed (attribute values must be encoded in double quotes) The current error messages are crap, that is totally right. They could certainly be more user-friendly. Have you got any ideas? You have no page, thus no way to edit! The admin interface should be always well-formed, having the offending portion in a textarea (or similar) for easy editing and an iframe for viewing. In any case, it is not allowable for companies to have their site down because of an user, even for just few minutes (if your lucky and find bug immediately)
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
Maybe so-called invalid HTML attributes are not the only solution,
but in my opinion it is a simple way to embed metadata within any
element.
What metadata are you talking about ? Microformats already exist.
I'm talking of any data that is related semantically to element and should
not be printed to the user or interact with default browser behaviour. There
is an example in the HTML5 spec of an element representing a spaceship in a
browser game, with data- attributes to provide fire / armour values
Imagine the spaceship has class spaceship, then i can write the following
css:
.spaceship:after {
display:block;
height: 10px;
width: attr(data-attack,px);
background-color: red;
color: white;
text-align: center;
content: Attack value attr(data-attack,string);
}
.spaceship:after:after {
display:block;
height: 10px;
width: attr(data-defence,px);
background-color: green;
color: white;
text-align: center;
content: Defence value attr(data-defence,string);
}
(The same behaviour can be achieved also with a @namespace rule, putting
non-standard attributes in an application-specific namespace)
Personally I prefer the latter (XML) solution, but there are context
where using XML serialization is not possibile (for example in user
generated content) so there is a definite need for a SGML way to add
custom attributes without conflicting with standards.
HTML5 is not derived from SGML anymore.
My fault, I meant the HTML serialization of HTML5.
Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. Imagine that such markup is then passed to a web application through XHR. In that case scripts aren't parsed and executed. In this case you have three ways to attach a behaviour: 2) on-event standard attributes (but they not performant since they're parsed every time the event fires and the cannot include chars like or , they need to be escaped) 3) assigning a class and some metadata using data-, then getElementsByClassName and addEventListener The same with CSS: you can use style for each element or data- attributes queried by attr() For what concerns browser support, these attributes are at all part of the DOM tree, so I can pass their names to getAttribute and setAttribute, but they don't get any special interface. It's the same in the XML serialization with different application-specific namespaces: they use only DOMAttr interface defined in DOM3Core and they're not part of any infoset (not part of ID list or NAME list) Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards.
