On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> Please don't encourage yet more sites to open new tabs when I didn't ask
> for it.
It's merely a new browsing context IIUC, not necessarily a new window (frame,
tab, tile or whatever it's called this year). Someone that understands t
On Mon, Apr 02, 2012, Ian Hickson wrote:
> On Tue, 21 Feb 2012, Bjartur Thorlacius wrote:
> >
> > Windows Explorer (the file manager) does for example offer users to edit
> > images upon right-click. I worry that if URI scheme handlers need not
> > only take c
On Wed, May 16, 2012 at 07:46:54AM +0200, Anselm Hannemann Web Development
wrote:
> The good thing on the picture element is that we have the possibility to
> serve other image-crops and with that the meaning could change so we could
> update the alt-attribute in the tag for every source-element
On 5/13/12, Kornel Lesiński wrote:
> By resolution I mean pixel density (regular vs "Retina" display), so this
> doesn't affect layout.
>
Ah, I must have misunderstood you.
>
> I can imagine layout complexity being tied to bandwidth (an image-rich
> design vs minimalistic text-only design), but I'
On 5/13/12, Kornel Lesiński wrote:
> I think layout (media queries) and optimisation cases are orthogonal and
> it would be a mistake to do both with the same mechanism.
>
My knee-jerk reaction to the above thought is that layout should be
done using CSS and any optimizations left up to the UA. A
On 5/5/12, Ian Hickson wrote:
> Note that even in this space, though, it's not the end of the story. For
> example, Chrome does more than just list the search autocomplete results;
> it also loads the first suggestion in the background, and mixes in results
> from local history search, etc. Other
On Wed, 14 Mar 2012 19:59:50 -, Christian Schmidt
wrote:
Bjartur Thorlacius skrev 2012-03-09 10:43:
I argue that putting user interface hints into a file transfer
protocol does cause problems
Would it be better if the Window-Target was somehow specified in the
of the destination page
On Wed, 14 Mar 2012 15:35:14 -, Gavin Peters (蓋文彼德斯)
wrote:
We're having great luck in Chrome with . If
Does not trigger this feature?
On 3/8/12, Christian Schmidt wrote:
> AFAIK no modern browser implements Window-Target, so I don't think the
> we need to reuse the old header name. Expanding Content-Disposition is
> also an option, e.g. "Content-Disposition: inline; target=_blank".
> Unfortunately we cannot use "Content-Disposit
sing context or not, and what other decisions depend on the
said information?
--
-,Bjartur
Þann lau 3.mar 2012 21:30, skrifaði Glenn Maynard:
Another use case: fixing Google's search results. They're currently
annoyingly broken: [snip]
Yes, Google is broken. But no, "Save As" is not the only thing that it
breaks.
In special,
href="http://www.google.com/url?sa=t&rct=j&q=l%C3%B6gbe
On Feb 24, 2012, at 12:18 AM, Michael Gratton wrote:
But in general, I recommend against this. Anything that can be
computed
should be computed on the server to obtain the canonical value,
otherwise
you open yourself up to attackers sending you inconsistent data.
While for applications whe
Þann þri 21.feb 2012 19:41, skrifaði James Hawkins:
Is this use case not fully handled by the UA specifying the
appropriate action when building the intent, e.g., the user
right-clicks on an image in a page and the UA constructs context menu
items for edit/share/etc. action?
Not if the image is b
Þann þri 21.feb 2012 18:44, skrifaði James Hawkins:
I'm not sure if the proposal was explicit enough, but for the RPH-esque
functionality in Web Intents, we activate WI in the same circumstances
RPH is activated, which is when links are activated in a page. Can you
elucidate how the scenarios yo
Þann mið 15.feb 2012 23:39, skrifaði James Hawkins:
* If |scheme| is specified, |action| *should* (must?) be ignored.
Why would you forbid distinguishing between actions on URIs? Postal and
retrieval of mail, for example, are quite distinct actions. As are
modification and retrieval of documen
.
IIRC the current RFC forbids, but mandates support for, such requests.
The seventeenth httpbis draft OTOH explicitly allows absolute URI in
request lines, at least to proxies.
bjartur@gamla ~ $ nc google.org 80
GET http://www.google.is/ HTTP/1.0
HTTP/1.0 200 OK
ably depends on particular
widths.
I surrender to broken websites.
--
-,Bjartur
document affect the layout of a previous part of the document,
as you seem to hint at, then hell is loose if we don't know them. Guessing
would be most unfortunate and surprising to layout designers.
* Well, the word does at least conform to the grammar of my native
language :/
--
-,Bjartur
content loaded. But yes, fast scrolling would break this. Not even knowing
the rough size of images before fetching them makes them hard to lay out
until they have been downloaded.
--
-,Bjartur
es up.
--
-,Bjartur
On 2/13/12, Gray Zhang wrote:
> We would like to present an authoring difficulty with regard to showing
> images on the Web with limited bandwidth, when deferring loading of certain
> or all images are preferable. We have some vague ideas about what
> browser/markup solutions instead of script sol
On Wed, 08 Feb 2012 17:16:36 -, Anselm Hannemann - Novolo
Designagentur wrote:
Okay, I talked with some disabled web developers and Accessibility
experts today and talked about the proposal of markup in alt-text.
This seems not to be a good idea as screenreader would read the tags
which
If using a single element for embedding in general would be
too hard on implementations (although the markup cleanliness is
tempting), can we not (re)use for both animated and still 2D
images?
On 2/7/12, Ashley Sheridan wrote:
> The main problem I see with that is that the tag doesn't have
> the same accessibility attributes, so you'd effectively lock out a lot
> of people using browsers that don't understand the context of the tag in
> this case. I think the better way is to add somet
On Mon, 06 Feb 2012 20:08:05 -, Matthew Wilcox
wrote:
On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
We're discussing HTTP here, so the content might just as well be raster
bitmaps.
Are we? Why, what makes HTTP the relevant factor? SPDY is the future and
already supported i
you should get media
type disambiguation for free.
--
-,Bjartur
could request a moderate
number of entries). The fallback and default of receiving the whole form
seems graceful enough to me.
--
-,Bjartur
or paginated wizards is a presentation
thing, that need not even have anything to do with HTTP. You can fetch
half the monolithic form and fetch the rest when the user has filled in
most of former half. Or you could fetch a whole form and paginate it.
--
-,Bjartur
the user, who should most of the time accept whatever
default the device manufacturer (or whoever writes software for said
device or class of devices) suggests.
We need servers to serve content.
--
-,Bjartur
orce. When bandwidth savings
are more important than download speed, and for tremendous size deltas
(such as for heavy graphics with available downsamples), please consider
HTTP 300 Multiple Choices client side negotiation and linking to multiple
representations of the same resource.
--
-,Bjartur
could be extended to express multitouch
capabilities. I don't think that would be useful for documents, but it
could allow for per-device reimplementation of zoom and scroll. I'll leave
deciding whether that's a fair use case to others. But that still doesn't
warrant requesting different content.
--
-,Bjartur
Feel free to propose e.g. Accept-Media to httpbis[1]. Bandwidth
negotiation would be most useful.
Do make note of the dynamic nature of many viewports* and the fact that
user agents may wish to render resources to multiple medias. The latter
is rare enough to tolerate an extra roundtrip. Resiz
On Wed, 01 Feb 2012 05:00:04 -, Brett Zamir wrote:
It would let anyone with web skills to have full creative control over
the browser UI which they can in turn easily share with others
regardless of the host browser those people are using, and without the
hassle of building and packagin
On Thu, 26 Jan 2012 21:43:07 -, Matthew Wilcox
wrote:
Obviously this is not right - perhaps I'm not understanding your use
case? Why would you want to specify an author as an attribute on the
element?
Not necessarily as an attribute, I would prefer an element.
What is wrong with:
C
king up Authors of Documents
An Article Written by Bjartur
This article was written to demonstrate how authorship might be
marked up. I sure hope it's valid!
mailto:bjar...@spam.la";>Bjartur Thorlacius
f the first href attribute in a
footer be assumed to identify the author? That seems bound to break, early
and often.
--
-,Bjartur
On Thu, 06 Oct 2011 17:56:23 -, Ian Hickson wrote:
The context here is how browsers display videos when you just navigate to
a video file directly. Much as with navigating to images, where the spec
says to use but doesn't require or disallow extra features, such as
the zoom feature most bro
On Wed, 05 Oct 2011 17:37:22 -, Ian Hickson wrote:
On Wed, 5 Oct 2011, Simon Pieters wrote:
video and audio should have controls="" and autoplay=""
The spec allows browsers to do that (in fact it explicitly calls out
autoplay=""), but do we really want to require one or the other? I can
On Mon, 26 Sep 2011 16:14:39 -, Philip Rogers wrote:
" It looks like editors using a textarea (such as codemirror) are
currently working around this by not drawing a cursor when there is a
selection."
In ignorance of the specificatory problem you describe, this seems sane
enough to m
Should @placeholder be renamed @eg, and used exclusively for example input?
On Thu, Sep 22, 2011 at 11:53 PM, Bjartur Thorlacius
wrote:
> The semantics of the placeholder and title attributes of inputs overlap
> slightly; the placeholder attribute may contain a hint to aid the user,
&
The semantics of the placeholder and title attributes of inputs overlap
slightly; the placeholder attribute may contain a hint to aid the user,
while title is to contain "other advisory text." I can think of two valid
uses of placeholder: example value, and the text "click here to type" or
Þann fös 9.sep 2011 19:27, skrifaði Benjamin Hawkes-Lewis:
On Thu, Sep 8, 2011 at 4:58 PM, Bjartur Thorlacius wrote:
Why use when you have onclick and a settable document.location? :)
I think there are sound reasons to provide user agent conformance
requirements for a@href and to allow it
Þann sun 11.sep 2011 18:44, skrifaði Michael A. Puls II:
I don't think < and > are in the list of safe URI characters. All
URI-based functions seem to percent-encode them too. Keeping them
encoded is definitely good for data URIs in text/plain documents so the
don't interfere with the < and > tha
Þann lau 10.sep 2011 21:15, skrifaði Daniel Holbert:
* Opera is interesting -- it can exhibit either the Firefox or WebKit
behaviors in tests A/B/C, depending on whether the data URI as an
embedded element (via iframe/img) or view it directly. When you view it
as an embedded element (in my testca
Þann mið 7.sep 2011 20:44, skrifaði Aryeh Gregor:
I've had some type of tests around for a while now, but they weren't
suitable for implementers. I've now recoded and reformatted them so
that they output a table of results using James Graham's
testharness.js. The link is here, but WARNING: it
A far greater problem is the lack of standardization of a protocol for
comment submittal. If the IETF were to standardize such a protocol,
would it not make more sense to distribute comments via the same channel?
That seems like a cleaner long-term solution than changing every stream
format out
> How exactly can I create a dynamic CMS website today with responsive images?
> I could manage my CSS file with my CMS which most of them don't support. I
> could minify the CSS on the fly but in reality and from performance view it's
> recommended to serve a static css file from a cookieless do
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles ("Click here to go to the next
page / page 4") and
Þann mán 22.ágú 2011 21:57, skrifaði Ehsan Akhgari:
On 11-08-18 6:09 PM, Bjartur Thorlacius wrote:
That seems to be of general utility. I recommend sending feature request
to implementors.
I think a much shorter path to success would be having a "Show/Hide All
Comments" button. :-)
Þann fim 18.ágú 2011 21:05, skrifaði Alfonso Martínez de Lizarrondo:
Now if someone had some bright idea to enable finding in the hidden text
that would be perfect, but the view source workaround is good enough for the
moment.
That seems to be of general utility. I recommend sending feature requ
Þann mið 17.ágú 2011 15:44, skrifaði Philip Jägenstedt:
I'd very much like to see feedback from other implementors. Are you
happy with treating autoplay and preload as "just hints" as in [4] or do
you think that we should specify them in greater detail? (This does not
preclude having user prefere
Þann fim 11. ágúst 2011 04:54, skrifaði Jukka K. Korpela:
It's debatable and irrelevant in this context what RTF, TeX, and
text/enriched are. The issue is whether HTML can express simple things
like bolding in quoted material - or, rather, whether such simple
expressivity is to be declared obsole
Þann mán 8.ágú 2011 20:31, skrifaði Simon Heckmann:
Well, not directly an answer to your question, but the use case I had in mind
is the following:
A large encrypted video (e.g. HD movie with 2GB) file is stored using the File
API, I then want to decrypt this file and start playing with only
On Sun, Aug 7, 2011 at 5:42 AM, Jukka K. Korpela wrote:
> Bjartur Thorlacius wrote:
> [...]
> Please note that this isn't about favoring HTML over presentational markup
> languages; none of the alternatives mentioned is a markup language at all.
RTF, TeX and text/enriched a
On 8/2/11, Ian Hickson wrote:
> Unfortunately, as I said above... what we want and what we get don't
> always match. There's not much we can do here to push authors further.
On the other hand, why accommodate the desires of authors? Why let
authors decide whether I use gold on black or black on wh
Þann þri 2.ágú 2011 09:04, skrifaði Henri Sivonen:
On Fri, 2011-07-29 at 22:39 +, Ian Hickson wrote:
Presentational markup may convey useful information, for example that a
quotation from printed matter contains an underlined word.
HTML is the wrong language for this kind of thing.
I di
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor:
> On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson wrote:
> The overarching counterpoint is that in-page UI *is* an authoring
> issue, because authors want to control exactly how their page looks
> and behaves. Browser/chrome UI issues shouldn't be
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor:
On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson wrote:
The overarching counterpoint is that in-page UI *is* an authoring
issue, because authors want to control exactly how their page looks
and behaves. Browser/chrome UI issues shouldn't be standar
Þann mán 1.ágú 2011 15:25, skrifaði Aryeh Gregor:
If you're doing useful password strength checks, regular expressions
won't cut it. For instance, you'll want to check against
dictionaries. Regex is only useful for crude and ineffective checks
like "must be at least six characters long with mi
On 7/11/11, Sean Connelly wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.
>
Fair point. I also worry about attackers removing a form a
Þann fös 22.júl 2011 23:09, skrifaði Kornel Lesiński:
2. Allow website to show additional information about the download,
while the download is taking place.
And to satisfy all three cases (without breaking links), it needs to be
done at HTTP level, by adding HTTP header (or multipart response?
Are JavaScript implementors willing to reimplement window.status? There
are obvious security problems with drawing an author-provided string
where a certain URI is expected, but could window.defaultStatus not set
the name (_NET_WM_NAME or equivalent) of the script's window and
window.status eit
Þann sun 17.júl 2011 22:46, skrifaði Ben Schwarz:
3)
As a web designer / developer
I want to be able to ascertain if another website has registered a custom
protocol handler in the user’s browser
So that I can knowingly design and implement an integration experience
4)
As a web designer / deve
Þann sun 17.júl 2011 18:36, skrifaði Jukka K. Korpela:
17.07.2011 18:07, Nils Dagsson Moskopp wrote:
I think it would be rather trivial. The string “ISBN” followed by
something that matches the syntax of ISBN numbers, perhaps allowing some
variation in punctuation, could be treated as an implici
Þann fös 15.júl 2011 21:34, skrifaði Darin Fisher:
2) Unlike rel=something, @download provides a way to specify the name
of the file to save. This makes the feature useful with data: URLs and
blob:
URLs (that are not backed by a single file). This is valuable to me because
I can imagine wantin
Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking:
2011/7/14 Ian Fette (イアンフェッティ):
One concern which was brought up was the ability to cause the user to
download a file from a third party site. I.e. this would allow
evil.com to trick the user into downloading an email from the users
webmail, or
On 7/15/11, Jukka K. Korpela wrote:
> Should it? Even when the book has no URL? If you expect urn:isbn:… to
> work anytime soon in any significant browser, you’re very optimistic.
>
Wikipedia and Amazon (among others) have all the mechanisms already.
Such ISBN handlers could even be registered by
On 7/15/11, Jukka K. Korpela wrote:
> 14.07.2011 16:10, Bjartur Thorlacius wrote:
>> I don't think author names are allowed in in HTML 5.
>
> They aren’t, but HTML5 linters (“validators”) won’t report the issue, as
> they don’t understand the meanings of words.
That d
On 7/14/11, Karl Dubost wrote:
> what about adding
>
> Save a Tree, Eat a beaver
>
This seems like the best solution to me. A filename hint has two use
cases: a suggestion for a local identifier, and providing a filename
extension for systems that use them to identify file types with
incomplete or
On 7/14/11, Ian Fette (イアンフェッティ) wrote:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, some
On 7/14/11, Kevin Marks wrote:
> There is another common pattern, seen in blogging a lot, of putting
> the citation at the top eg
> As http://www.gyford.com/phil/";
> class="url" rel="acquaintance met colleague"> class="fn">Phil wrote about the href="http://www.gyford.com/phil/writing/2009/04/28/
Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela:
14.07.2011 13:49, Karl Dubost wrote:
Sur un pétale de lotus, j'écrivis ces quelques vers :
«Même si l'on vient me chercher
Comment, abandonnant la rosée
De pareil lotus,
Retournerai-je
Dans le monde changeant et frivole ? »
et j'envoyais ce
Þann fim 14.júl 2011 09:38, skrifaði Oli Studholme:
in graphic design a footer contains supplementary information about
the content it follows. the spec initially disallowed ‘fat footers’,
but the naming and common usage would have led to people using them
for fat footers regardless of the spec.
.
On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
wrote:
I'm not arguing against rendering attribution. On
the contrary, IMO user agents should render at least the title of the cited
resource.
This is a can of worms as authors will want control over both content
and style. Attributes t
On 7/8/11, Jeremy Keith wrote:
Bjartur wrote:
Citation will most likely contain the cited resource (@cite), the title
of the cited resource (@title) and the date and optionally time of the
quote (@datetime?).
All three of which are invisible and so do not match the use cases that Oli
has
Þann sun 10.júl 2011 08:08, skrifaði Alex Vincent:
/**
* Check if a password field's value matches another.
*
* @param otherPassword Another password element.
*
* @throws Error if this.type != "password"
* @throws Error if other.type != "password"
*
* @returns Boolean True if the
Þann lau 9.júl 2011 04:29, skrifaði Hugh Guiney:
6.1 On that note, why is the spec enabling the use of unstyled spans
to achieve alternative rendering? Doesn't this give meaning (however
contextual) to an element that is supposed to be semantically neutral?
Can you think of any other uses for s
Þann fös 8.júl 2011 11:20, skrifaði Jeremy Keith:
3) The solution that Oli has proposed (allowing footer within
blockquote to include non-quoted information) is an elegant one, in
my opinion. I can think of some solutions that would involve putting
the attribution data outside the blockquote and
Þann fim 7.júl 2011 05:30, skrifaði Felix Halim:
On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost wrote:
http://uhunt.felix-halim.net/id/339
I'll look into your site when I've slept, but FYI, you're mandated to
provide a title for your document. You should probably provide a title
of "uHunt", and
Þann fös 1.júl 2011 03:22, skrifaði Felix Halim:
I'm looking for a solution that doesn't require modifying anything
except adding a manifest.
I recommend fixing your website. As others have stated, this has
practical benefits, in the online as well as the offline case.
As I said before, sep
Ask HTTP implementors to store a potentially stale fallback copy for
offline use when an authoritative copy is unavailable. Even HTTP
caches are allowed to return stale responses as long as they warn
their clients (so they can warn their clients or fetch an
authoritative copy via another route).
Br
On 6/14/11, Tab Atkins Jr. wrote:
> On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernst wrote:
>> Consider:
>> I like apples, pears, grapes, but not bananas. Nor do I like
>> peaches.
>> and:
>> I like
>> * apples
>> * pears
>> * grapes
>> but not bananas. No
On 6/9/11, Mikko Rantalainen wrote:
> 2011-06-07 18:07 EEST: Bjartur Thorlacius:
>> Elaborate; they both refer to the next resource in a sequence of
>> documents. Note that a document may be an element in multiple
>> sequences of documents.
>
> Notice the word "
On 3/11/11, Dave Kok wrote:
> This may very well be a natural consequence of having a proposal like
> this implemented. But this would assume that implementers feel that
> having a logout button embedded into documents is considered superior
> then having a UA provided logout button. Otherwise suc
On 6/7/11, Mikko Rantalainen wrote:>
> Note that the "next page" button may or may not match with rel="next"
> and as such, I think that there should be additional method for
Elaborate; they both refer to the next resource in a sequence of
documents. Note that a document may be an element in multi
On 6/6/11, Boris Zbarsky wrote:
> My point was that there should be _a_ standardized way that sites can
> use to get consistent behavior across browsers. Content-Disposition
> headers see like that way to me.
>
More importantly there should be an implementation defined convention
so users get con
On 6/5/11, Boris Zbarsky wrote:
>> Why need they be? This isn't Bittorrent.
> I think you completely misunderstood my mail... the point is that
> browses do NOT all use the last non-empty path component; some try to
> guess a filename based on the query params, in various ways.
No, I understood -
On 6/3/11, Boris Zbarsky wrote:
> On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
>>> Note that some browsers will do weird parsing of the query params to
>>> attempt to extract a "useful filename". That seems strictly worse than
>>> just using Content-Di
On 6/3/11, Boris Zbarsky wrote:
>http://mysite.org/generate_progress_report.php?quarter=Q12010
>
> When saving, it would be good to use something like "Progress report of
> Q1 2010" as the filename. But that's not "part of the URI" in any sense.
>
So you're suggesting using the title as the f
On 5/26/11, Michal Zalewski wrote:
> Keep in mind that the mechanism *is* extremely imperfect. It only
> works for MIME types and extensions recognized by the browser (which
> is a small list). There's a large disconnect between this set, the set
> handled by the OS, and the actual logic used to c
On 5/31/11, Felix Halim wrote:
> On Mon, May 30, 2011 at 10:39 PM, Bjartur Thorlacius
> wrote:
>
> The dynamic resources only updated if the user visit the particular
> app cached web-page.
>
Yeah, that's logical. Caches should still be allowed to refetch
resources just
Þann mán 30.maí 2011 03:42, skrifaði Felix Halim:
Hmm.. yes, I think "unlimited" is a bad word (I just use it because
currently App Cache quota is unlimited).
Let me explain my need for pageStorage in a different way:
Suppose I have a web page and want to store it in an App Cache. This
web page
On 5/28/11, Felix Halim wrote:
> To summarize, the pageStorage offers "unlimited" storage for dynamic
> content for the App Cached web pages.
User agents may store expired pages for offline use. Internet Explorer
and Firefox have 'Work offline' modes automatically enabled on
complete disconnection
On 5/16/11, Ian Hickson wrote:
> On Mon, 16 May 2011, Adam Shannon wrote:
>> I'd rather see UA's implement better controls on their end than see an
>> API which could be largely abused. (Drag and drop browser controls over
>> tons of sites asking for permission to be the default.)
>
> I agree. Not
On 5/6/11, Charles McCathieNevile wrote:
> On Thu, 05 May 2011 21:41:24 +0200, Bjartur Thorlacius
>> Of course, if the site requests coordinates, it's up to the user
>> whether they come from /dev/gps or /dev/tty (or /n/3D Globe).
>
> Yeah, in principle. But given that
On 5/5/11, Charles McCathieNevile wrote:
> On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius
> wrote:
>
>> On 5/3/11, Cameron Heavon-Jones wrote:
>>> There are a number of resources which are thought of having an
>>> 'application' scope which may
e amount
> of effort put into them...
>
Sadly, the things authors desire may conflict with the things users
desire. I also desire control over navigation links (among many other
things). From authors, I desire only content.
Bjartur Thorlacius
yet another End-User(tm)
On 5/3/11, Cameron Heavon-Jones wrote:
> I would agree a command-level authorization is a better default, if only
> because it is necessary to have this level of granularity available.
>
Agreed.
> The quantity of permission requests can be managed in an effective manner by
> the agent allowing th
On 3/21/11, Philip Jägenstedt wrote:
> On http://foolip.org/microdatajs/live/#json I have a "Download it!"
> function which uses data: URLs to save JSON generated by JavaScript. The
> only real limitation with this approach is that one cannot suggest a file
> name, so in Opera the suggested file n
On 4/28/11, Ian Hickson wrote:
> On Thu, 28 Apr 2011, Bjartur Thorlacius wrote:
>> All current UAs would understand the link (and most probably present it
>> to the user). Inline presentation is an optional luxury: the important
>> thing is getting the media across. I, fo
1 - 100 of 207 matches
Mail list logo
