Re: Acceptable for CSS to add a "window.CSS" global?

[Tab Atkins Jr.]

On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson  wrote:
> On Mon, 13 Aug 2012, Tab Atkins Jr. wrote:
>> The CSSWG would like to add a new top-level object called "CSS" that we
>> can hang several functions and constructors off of, so that we can avoid
>> the excessive verbosity that's probably required if we just put
>> everything on window. [...]
>>
>> Does anyone see any problems with this?  Do we think there's a
>> significant compat risk to claiming an all-caps "CSS" variable?
>
> Seems reasonable in principle, but there's a risk of running into Conway's
> law if we decide what goes into this object based on which working group
> devlops it rather than on what makes sense to go there from the author
> perspective. So it's hard to answer the question without specific details
> of what APIs are intended for such an object.

The Conway's Law concern is reasonable, though minor.  Noted.


>> (Right now, the only thing we want to add is a "supports()" function,
>> which is the API version of the upcoming @supports rule.  In the future,
>> we'd like to add things like the CSSOM Value API constructors to it, so
>> authors can do a simple "new CSS.px(5)" rather than "new
>> CSSPixelComponentValue(5)".)
>
> As a general rule, @supports and supports() sound like they're run into
> the antipattern where browsers with poor testing return true (despite
> having bad implementations -- the implementor just doesn't realise it),
> browsers with rigoroush but conservative developers return false (despite
> having good implementations -- the implementator doesn't want to say "yes"
> until they can avoid poisoning the value, but they end up waiting longer
> than necessary), and browsers with poor code review and lots of
> enthusiastic contributors return true (despite having no implementation at
> all -- I've often seen people start off by implementing the feature test
> and only looking at doing the feature later).

@supports was designed very specifically to make this as small of a
problem as possible.

If a browser supports "foo: bar;" well enough to actually parse it and
keep it around, it's - by definition - good enough for authors to use
it.  While it's theoretically possible that a particular browser's
implementation is really shitty so that you don't want to use it, in
practice I don't think that's ever been a problem (or if it has, it's
been rare enough that I don't remember it).

This is why we didn't provide a simple form that just lets you ask for
a property name - you have to give a full value, presumably something
that you're actually using in the code.


> There's also a granularity
> issue. In the olden days it was common for browsers to support 'display:
> inline' and it was common for browsers to support 'border', they just
> didn't support them together. It was common for years for browsers to
> support 'position:absolute' and to support ':before', but for years they
> didn't support them together (at first because the spec said not to; later
> because they hadn't caught up).

Valid in principle, but I don't think it's a big deal.  There are some
issues like that, but authors can know about them and work around
them.

> And finally there's the issue of browser
> testing sites using the feature test as a proxy for conformance testing,
> with all the resulting pressures (e.g. browsers with lower resolve get
> pressured into returning true while browsers with higher standards end up
> dinged in the reviews).

This is no different than today - badly-written "testing" sites
sometimes use the mere presence of an unprefixed property as a
guarantee of conformance.  Using @supports to test for that is merely
a slightly easier way to do that kind of "test".  We don't seem to
have problem with unprefixing and pressure due to this today.

> We saw this a lot with the equivalent DOM APIs like hasFeature(). In
> practice, they became completely useless and Anne worked hard to sunset
> them in DOM Core.
>
> I would recommend and urge great caution. There be dragons on this path.

The failure of hasFeature() greatly informed the design of this feature. ^_^

If you'd like to discuss the supports() function further, could you do
it on www-style?  I'd prefer this thread to stay on the original
subject.

~TJ

Re: Acceptable for CSS to add a "window.CSS" global?

[Ian Hickson]

On Mon, 13 Aug 2012, Tab Atkins Jr. wrote:
>
> The CSSWG would like to add a new top-level object called "CSS" that we 
> can hang several functions and constructors off of, so that we can avoid 
> the excessive verbosity that's probably required if we just put 
> everything on window. [...]
> 
> Does anyone see any problems with this?  Do we think there's a 
> significant compat risk to claiming an all-caps "CSS" variable?

Seems reasonable in principle, but there's a risk of running into Conway's 
law if we decide what goes into this object based on which working group 
devlops it rather than on what makes sense to go there from the author 
perspective. So it's hard to answer the question without specific details 
of what APIs are intended for such an object.


> (Right now, the only thing we want to add is a "supports()" function, 
> which is the API version of the upcoming @supports rule.  In the future, 
> we'd like to add things like the CSSOM Value API constructors to it, so 
> authors can do a simple "new CSS.px(5)" rather than "new 
> CSSPixelComponentValue(5)".)

As a general rule, @supports and supports() sound like they're run into 
the antipattern where browsers with poor testing return true (despite 
having bad implementations -- the implementor just doesn't realise it), 
browsers with rigoroush but conservative developers return false (despite 
having good implementations -- the implementator doesn't want to say "yes" 
until they can avoid poisoning the value, but they end up waiting longer 
than necessary), and browsers with poor code review and lots of 
enthusiastic contributors return true (despite having no implementation at 
all -- I've often seen people start off by implementing the feature test 
and only looking at doing the feature later). There's also a granularity 
issue. In the olden days it was common for browsers to support 'display: 
inline' and it was common for browsers to support 'border', they just 
didn't support them together. It was common for years for browsers to 
support 'position:absolute' and to support ':before', but for years they 
didn't support them together (at first because the spec said not to; later 
because they hadn't caught up). And finally there's the issue of browser 
testing sites using the feature test as a proxy for conformance testing, 
with all the resulting pressures (e.g. browsers with lower resolve get 
pressured into returning true while browsers with higher standards end up 
dinged in the reviews).

We saw this a lot with the equivalent DOM APIs like hasFeature(). In 
practice, they became completely useless and Anne worked hard to sunset 
them in DOM Core.

I would recommend and urge great caution. There be dragons on this path.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Drag & Drop Web Apps

[Ian Hickson]

On Fri, 10 Aug 2012, Joran Greef wrote:
>
> Given the advance of HTML 5, and in the interest of developing web apps with 
> average functionality, would it now be possible to:
> 
> 1. Drag files and folders into a web app?

Files is specced and implemented.

Folders is implemented in Chrome experimentally, and there's a ton of 
feedback about it pending in the WHATWG feedback buckets, but I'm not 
aware of interest from other browser vendors so I've left it languishing 
for now. If it's something other vendors want, it could probably be added 
without too much trouble (especially if we just matched Chrome, so I don't 
have to come up with anything ;-) ).


> 2. Drag files and folders out of a web app?

Dragging files out is specced. Not sure about implementation status.

Dragging folders would be added as soon as we added dragging folders in 
(the API is ready for for it, I just need an interface to represent 
folders which I would plug into it).


> 3. Drag a spreadsheet out of a web app onto the icon of Excel in the 
> dock and have it open in Excel?

That's possible today, in theory, assuming you can describe the data in a 
form Excel supports.


> 4. Monitor that same spreadsheet's content (originally provided by the 
> web app) for changes when the user edits it and presses CTRL+S?

I'm not aware of any work on this front. It's something we could support 
if there's interest, but I expect most of the interest on this front will 
be superseded with something like Web Intents.


> Or is it only possible to drag things into a browser window but not back 
> out and nothing else?

The API is entirely symmetric, so both are possible.


> Can a user drag a piece of data into a browser window… and then drag it 
> back out?

Yes.


> For example, a user may want to use a Contacts web app, and drag a 
> contact out the browser window as a piece of vcard data and land this 
> onto the Contacts app in the dock, which would then import the contact, 
> all in a single mouse gesture?

Assuming the Contacts app in the dock is a _Web_ app, I'm not sure we'd 
support dropping onto the icon itself. But in principle this is possible.


> Or is it not possible to provide that kind of user experience?

It should be possible.


> For example, a user may want to use a PDF web app, and transfer a piece 
> of PDF data to the Preview app, but be forced to click a link to 
> download the PDF, click the very small "Keep" button next to the "This 
> type of file can harm your computer. Do you want to keep anyway?" 
> warning, and then drag the PDF onto the Preview app, and then go to the 
> Downloads folder to delete the "download". At least 5 mouse clicks and 
> then a CMD+backspace to accomplish what (from the user's point of view 
> at least) should have only taken one drag and drop?

That sounds like an issue with the specific browser.


> And then this may be vendor specific, but if a user created a piece of 
> PDF data and dragged it into the browser window in the first place, does 
> it still make sense to warn them that "this type of file can harm your 
> computer"?

This is vendor-specific.


> The browser takes on too much responsibility for things it can't 
> possibly reason about, and seeks not enough advice from the user where 
> it could. It often seems that the browser is built to lecture the user, 
> rather than the other way round. I use the browser everyday at work, and 
> sometimes you have to ask yourself: who's serving who. Does the user 
> serve the browser, or does the browser serve the user?

The browser serves the user, but many of the users it serves are not as 
educated about security risks. (And many of those who incorrectly think 
they are educated are the most at risk.)

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[webcomponents] Progress Update

[Dimitri Glazkov]

Greetings, Public-Webapp-lings,

It's time for the sem-regular update from the Web Components-land.

SHADOW DOM 
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978&hide_resolved=1):

Quite a few updates, from minor clarification tweaks to rather massive updates.

The events section, algorithms, and example have been thoroughly
reworked, primarily based on the field feedback from WebKit
implementation.

The CSS-related stuff has been remodeled so much since FPWD, it could
be called "all new":
* Clearer and better defined language around distribution and styles
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=17674 and many more)
* Using @host at-rule, rather than :host:
http://dvcs.w3.org/hg/webcomponents/rev/32a744c2c2f9
* The @host at-rule contains rulesets that match only shadow host:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18483
* Foundational plumbing for shared stylesheets:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818
* resetStyleInheritance for :
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17472

HTML TEMPLATES 
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476&hide_resolved=1):
* Tony joins the editor team:
http://dvcs.w3.org/hg/webcomponents/rev/654a63639c10

CUSTOM ELEMENTS
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968&hide_resolved=1):
Lots of interesting discussion on bugs:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18533,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18534,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18535

ADDITIONAL WAYS TO STAY UPDATED:
* https://plus.google.com/b/103330502635338602217/
* http://dvcs.w3.org/hg/webcomponents/rss-log
* follow the meta bugs for each section.

:DG<

Re: IndexedDB: ambiguity around createIndex order-of-operations

[Alec Flett]

On Mon, Aug 13, 2012 at 12:23 PM, Jonas Sicking  wrote:

>
> I think the two puts need to succeed. Implementation would be very
> complex and suboptimal otherwise. You need to know that there's a
> pending index-create operation and wait with firing success values for
> any requests until both all requests have succeeded and the
> index-create operation has succeeded before you can fire any events.
>
>  Yeah - I think this is just easier for developers to wrap their head
around too.

On top of that you can get circular dependencies I think since if one
> of the two put operations failed for reasons unrelated to the
> index-create, then the index-create operation would succeed.
>
> The way we handle this in gecko is that we treat index-create as a
> normal async operation.


FWIW, this is exactly what we mostly do in Chrome - and during some code
refactoring, we realized we had a choice of behaviors and went to the spec
for guidance..



>
> Suggestions for how to clarify this in the spec is welcome. At the
> very least we need a bug.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551

Alec


> / Jonas
>

[Bug 18551] New: [IndexedDB] Ambiguity about operations preceding a failed createIndex.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551

   Summary: [IndexedDB] Ambiguity about operations preceding a
failed createIndex.
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: alecfl...@chromium.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


jsbell and I have been discussing a possible ambiguity in the IndexedDB spec
w.r.t. error handling around createIndex calls.


In particular, createIndex() is supposed to behave somewhat synchronously in
that calling:


the implementation must create a newindex and return an IDBIndex object
representing it.

so that this is reasonable:
objectStore.createIndex('foo',...)
objectStore.put(...)
objectStore.index('foo').get(...)

But at the same time createIndex() behaves somewhat asynchrnously - while the
metadata for the index needs to be there immediately, the actual indexing data
doesn't have to:

> In some implementations it's possible for the implementation to 
> asynchronously run into problems creating the index after the createIndex 
> function has returned. For example in implementations where metadata about 
> the newly created index is queued up to be inserted into the database 
> asynchronously, or where the implementation might need to ask the user for 
> permission for quota reasons. Such implementations must still create and 
> return an IDBIndex object. Instead, once the implementation realizes that 
> creating the index has failed, it must abort the transaction using thesteps 
> for aborting a transaction using the appropriate error as error parameter. 

The issue in question is how to handle this:

objectStore.put({"foo": 1, "message": "hello"});
req = objectStore.put({"foo": 1, "message": "goodbye"});
objectStore.createIndex("foo", "foo", {unique: true});// will fail
asynchronously

The question is, should req's onerror fire or not? 

>From discussion on the list, I think most folks agree that both put()'s should
succeed, but the spec needs to be clear on this.


A suggested clarification, but I'm sure it could be worded better.

In some implementations it's possible for the implementation to asynchronously
run into problems creating the index [data] after the createIndex function has
returned. For example in implementations where [indexing data about existing
objects in the database] is queued up to be inserted into the database
asynchronously, or where the implementation might need to ask the user for
permission for quota reasons. Instead, once the implementation realizes that
creating the objectStore has failed, it must abort the transaction using the
steps for aborting a transaction using the appropriate error as error
parameter. [If asynchronous write operations within the same transaction
precede the createIndex, and they are the cause of the failure to create the
index, they should not fail for this reason.] For example if creating the index
failed due to quota reasons, QuotaError must be used as error and if the index
can't be created due to unique constraints, ConstraintError must be used as
error [and preceding requests which created these constraint violations should
not fail.]

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: IndexedDB: ambiguity around createIndex order-of-operations

[Jonas Sicking]

On Mon, Aug 13, 2012 at 11:16 AM, Alec Flett  wrote:
> jsbell and I have been discussing a possible ambiguity in the IndexedDB spec
> w.r.t. error handling around createIndex calls.
>
>
> In particular, createIndex() is supposed to behave somewhat synchronously in
> that calling:
>
>>
>> the implementation must create a newindex and return an IDBIndex object
>> representing it.
>
>
> so that this is reasonable:
> objectStore.createIndex('foo',...)
> objectStore.put(...)
> objectStore.index('foo').get(...)
>
> But at the same time createIndex() behaves somewhat asynchrnously - while
> the metadata for the index needs to be there immediately, the actual
> indexing data doesn't have to:
>
>> In some implementations it's possible for the implementation to
>> asynchronously run into problems creating the index after the createIndex
>> function has returned. For example in implementations where metadata about
>> the newly created index is queued up to be inserted into the database
>> asynchronously, or where the implementation might need to ask the user for
>> permission for quota reasons. Such implementations must still create and
>> return an IDBIndex object. Instead, once the implementation realizes that
>> creating the index has failed, it must abort the transaction using thesteps
>> for aborting a transaction using the appropriate error as error parameter.
>
>
> The issue in question is how to handle this:
>
> objectStore.put({"foo": 1, "message": "hello"});
> req = objectStore.put({"foo": 1, "message": "goodbye"});
> objectStore.createIndex("foo", "foo", {unique: true});// will fail
> asynchronously
>
> The question is, should req's onerror fire or not? Depending on the
> implementation, createIndex() could fully create/index the whole 'foo' index
> before the put's are serviced, which means by the time the 2nd put()
> happens, the index already says that the put is invalid. On the other hand,
> if the actual indexing happens later (asynchronously), but in the order
> written (i.e. put(), put(), createIndex) then the 2nd put would succeed, and
> THEN the index gets created. In either case the transaction is aborted.
>
> From a developer's perspective, I feel like making the 2nd put() fail is
> really confusing, because it seems really strange that a later API call
> (createIndex) could make an earlier put() fail - you might remove the
> createIndex() to debug the code and then magically it would succeed! On the
> other hand, that behavior does allow the creator to preventBubble() to
> prevent the failure, which could prevent the transaction from failing.
>
> In either case, I feel like this is a fairly degenerate case and I feel like
> we need to optimize this behavior for debugging, since I don't think normal
> usage patterns of IndexedDB should be doing this.

I think the two puts need to succeed. Implementation would be very
complex and suboptimal otherwise. You need to know that there's a
pending index-create operation and wait with firing success values for
any requests until both all requests have succeeded and the
index-create operation has succeeded before you can fire any events.

On top of that you can get circular dependencies I think since if one
of the two put operations failed for reasons unrelated to the
index-create, then the index-create operation would succeed.

The way we handle this in gecko is that we treat index-create as a
normal async operation. However we create the meta-data on the main
thread so that we can return the index object. But otherwise the
index-create operation is a normal async operation which runs on the
database thread in the same order as normal requests. The only
difference is that we don't expose the request object anywhere.

Suggestions for how to clarify this in the spec is welcome. At the
very least we need a bug.

/ Jonas

Re: Acceptable for CSS to add a "window.CSS" global?

[Dimitri Glazkov]

Interesting. Perhaps that's where CSSOM for Regions could live?

:DG<

On Mon, Aug 13, 2012 at 11:19 AM, Tab Atkins Jr.  wrote:
> The CSSWG would like to add a new top-level object called "CSS" that
> we can hang several functions and constructors off of, so that we can
> avoid the excessive verbosity that's probably required if we just put
> everything on window.
>
> (Right now, the only thing we want to add is a "supports()" function,
> which is the API version of the upcoming @supports rule.  In the
> future, we'd like to add things like the CSSOM Value API constructors
> to it, so authors can do a simple "new CSS.px(5)" rather than "new
> CSSPixelComponentValue(5)".)
>
> Does anyone see any problems with this?  Do we think there's a
> significant compat risk to claiming an all-caps "CSS" variable?
>
> ~TJ
>

Acceptable for CSS to add a "window.CSS" global?

[Tab Atkins Jr.]

The CSSWG would like to add a new top-level object called "CSS" that
we can hang several functions and constructors off of, so that we can
avoid the excessive verbosity that's probably required if we just put
everything on window.

(Right now, the only thing we want to add is a "supports()" function,
which is the API version of the upcoming @supports rule.  In the
future, we'd like to add things like the CSSOM Value API constructors
to it, so authors can do a simple "new CSS.px(5)" rather than "new
CSSPixelComponentValue(5)".)

Does anyone see any problems with this?  Do we think there's a
significant compat risk to claiming an all-caps "CSS" variable?

~TJ

IndexedDB: ambiguity around createIndex order-of-operations

[Alec Flett]

jsbell and I have been discussing a possible ambiguity in the IndexedDB
spec w.r.t. error handling around createIndex calls.


In particular, createIndex() is supposed to behave somewhat synchronously
in that calling:


> the implementation *must* create a 
> newindex
>  and
> return an 
> IDBIndex
>  object
> representing it.


so that this is reasonable:
objectStore.createIndex('foo',...)
objectStore.put(...)
objectStore.index('foo').get(...)

But at the same time createIndex() behaves somewhat asynchrnously - while
the metadata for the index needs to be there immediately, the actual
indexing data doesn't have to:

In some implementations it's possible for the implementation to
> asynchronously run into problems creating the index after the createIndex
> function has returned. For example in implementations where metadata about
> the newly created index is queued up to be inserted into the database
> asynchronously, or where the implementation might need to ask the user for
> permission for quota reasons. Such implementations *must* still create
> and return an 
> IDBIndex
>  object.
> Instead, once the implementation realizes that creating the index has
> failed, it *must* abort the transaction using thesteps for aborting a
> transaction
>  using
> the appropriate error as error parameter.


The issue in question is how to handle this:

objectStore.put({"foo": 1, "message": "hello"});
req = objectStore.put({"foo": 1, "message": "goodbye"});
objectStore.createIndex("foo", "foo", {unique: true});// will fail
asynchronously

The question is, should req's onerror fire or not? Depending on the
implementation, createIndex() could fully create/index the whole 'foo'
index before the put's are serviced, which means by the time the 2nd put()
happens, the index already says that the put is invalid. On the other hand,
if the actual indexing happens later (asynchronously), but in the order
written (i.e. put(), put(), createIndex) then the 2nd put would succeed,
and THEN the index gets created. In either case the transaction is aborted.

>From a developer's perspective, I feel like making the 2nd put() fail is
really confusing, because it seems really strange that a later API call
(createIndex) could make an earlier put() fail - you might remove the
createIndex() to debug the code and then magically it would succeed! On the
other hand, that behavior does allow the creator to preventBubble() to
prevent the failure, which could prevent the transaction from failing.

In either case, I feel like this is a fairly degenerate case and I feel
like we need to optimize this behavior for debugging, since I don't think
normal usage patterns of IndexedDB should be doing this.

Alec

Re: [FileAPI] blob: protocol need a content-length header

[Arun Ranganathan]

Benjamin,

I filed the following:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18548

I think we should add Content-Length.

-- A*

On Aug 12, 2012, at 5:41 PM, Benjamin BERNARD wrote:

> I build de demo script (for firefox) here : 
> http://experiments.benvii.com/blob_content_length/
> You will also notice that the player's load event isn't called.
> 
> Content-Length should be added to firefox (maybe open a ticket on 
> https://bugzilla.mozilla.org/) but it should also be recommended in the 
> section "11.7.3. Request and Response Headers" of the spec.
> 
> Thanks for responding.
> 
> Benjamin BERNARD
> 
> 
> Le 12/08/2012 21:23, Jonas Sicking a écrit :
>> On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
>>   wrote:
>>> Hi,
>>> I was developing an offline music web App when I discover that is no
>>> "Content-length" header specified here :
>>> http://www.w3.org/TR/FileAPI/#ProtocolExamples
>>> So when you play an audio/video file stored as a blob (under a blob URI)
>>> it's considered by the player as streaming content which means you can't get
>>> the duration of a song for instance (it has an infinite duration). I think
>>> it might be the consequence of not providing a content-length header.
>>> 
>>> I experienced it using Firefox I heard Internet Explorer already provide
>>> this header.
>>> 
>>> Moreover, I don't understand why there is no content-length header
>>> recommended in the spec because when you use URL.createObjectURL(blob), blob
>>> has a finished size (correct me if I'm wrong). So a content-length header
>>> should also be provided and recommended in the spec.
>> Yes, I agree, we should have a content-length header similar to the
>> content-type header.
>> 
>> In Gecko things are a bit complicated because we don't have headers on
>> anything but http channels. But we do have the concept of a length of
>> a response for all channels so that should take care of it. Not sure
>> off the top of my head why it doesn't. Filing a bug with an example
>> would be great.
>> 
>> / Jonas
> 

[Bug 18548] New: Add a Content-Length header to Blob URI request-response semantics

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18548

   Summary: Add a Content-Length header to Blob URI
request-response semantics
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: a...@mozilla.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


>From listserv traffic:

"I build de demo script (for firefox) here :
http://experiments.benvii.com/blob_content_length/
You will also notice that the player's load event isn't called.

Content-Length should be added to firefox (maybe open a ticket on
https://bugzilla.mozilla.org/) but it should also be recommended in the section
"11.7.3. Request and Response Headers" of the spec."

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Web Components Suggestion

[Brian Kardell]

On Aug 13, 2012 4:49 AM, "Florian Bösch"  wrote:
>
> On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith  wrote:
>>
>> There is no conceivable conformance checker that's going to allow the use
>> of completely arbitrary tag names. It doesn't matter what formalism it
uses.
>> To allow custom tag names and still be able to check the conformance of
>> normal tag names, the only possibility is to limit the custom tag names
to
>> some recognized prefix -- e.g., x-fancyButton or whatever.
>
> 

For clarity, you don't mean literally x:  right?  On the other hand, most
people do mean literally x-.

Re: Web Components Suggestion

[Florian Bösch]

On Mon, Aug 13, 2012 at 12:38 PM, Chaals McCathieNevile wrote:

> On Mon, 13 Aug 2012 10:47:22 +0200, Florian Bösch 
> wrote:
>
>  On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith  wrote:
>>
>>  There is no conceivable conformance checker that's going to allow the
>>> use of completely arbitrary tag names. It doesn't matter what formalism
>>> it uses.
>>> To allow custom tag names and still be able to check the conformance of
>>> normal tag names, the only possibility is to limit the custom tag names
>>> to some recognized prefix -- e.g., x-fancyButton or whatever.
>>>
>>
>> 
>>
>
> Yes, XML has a way to make this work. But the people who don't get
> namespaces (a huge proportion of those publishing content or build the
> content content generation tools that were used in the last decade *on the
> public web*) have convinced us* that this is not an option for HTML.
>
> On the other hand, a log of programming languages manage to run a compiler
> that recognises arbitrary elements based on a grammar and an "import"
> declaration of some kind.
>
> In other words, they use a simplistic namespace mechanism (without the
> collision-control).
>
> *For some definition of us. For those who have worked happily with
> namespaces over the last decade, writing HTML5 as XHTML is a reasonable
> option, if the browsers don't scrap their XML capability.
>
I'm not a fan of XML or anything. But if you want to do namespacing it'd be
worth thinking about to do it properly before coming up with another
hodgepodge prefixing solution.

Re: Web Components Suggestion

[Chaals McCathieNevile]

On Mon, 13 Aug 2012 10:47:22 +0200, Florian Bösch  wrote:


On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith  wrote:

There is no conceivable conformance checker that's going to allow the  
use of completely arbitrary tag names. It doesn't matter what formalism

it uses.
To allow custom tag names and still be able to check the conformance of
normal tag names, the only possibility is to limit the custom tag names  
to some recognized prefix -- e.g., x-fancyButton or whatever.





Yes, XML has a way to make this work. But the people who don't get
namespaces (a huge proportion of those publishing content or build the
content content generation tools that were used in the last decade *on the
public web*) have convinced us* that this is not an option for HTML.

On the other hand, a log of programming languages manage to run a compiler  
that recognises arbitrary elements based on a grammar and an "import"  
declaration of some kind.


In other words, they use a simplistic namespace mechanism (without the  
collision-control).


*For some definition of us. For those who have worked happily with  
namespaces over the last decade, writing HTML5 as XHTML is a reasonable  
option, if the browsers don't scrap their XML capability.


cheers

Chaals

--
Chaals - standards declaimer

Re: Web Components Suggestion

[Florian Bösch]

On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith  wrote:

> There is no conceivable conformance checker that's going to allow the use
> of completely arbitrary tag names. It doesn't matter what formalism it
> uses.
> To allow custom tag names and still be able to check the conformance of
> normal tag names, the only possibility is to limit the custom tag names to
> some recognized prefix -- e.g., x-fancyButton or whatever.