Re: [WSG] HTML5 offline storage question
Asking why not just use the cache is a valid question. In this case, using HTML5 storage to house files doesn't seem to be tapping into all HTML5 storage can do--but it's not violating what storage can do either (so far as I know). HTML5 storage is like cookies: Simply put, it’s a way for web pages to store named key/value pairs locally, within the client web browser. Like cookies, this data persists even after you navigate away from the web site, close your browser tab, exit your browser, or what have you. Unlike cookies, this data is never transmitted to the remote web server (unless you go out of your way to send it manually). That's from: http://diveintohtml5.org/storage.html#localstorage So, HTML5 storage is more for data storage--storing key/value pairs (like massive cookies)--than just a repository of files. This is how I understand it. Others may know more. I'd think a iPhone/iPad native app would want to look beyond HTML5 storage and into File Management. But if this is a web app, then HTML5 storage might be the only option. But I'm far from being an expert. -jody On Aug 9, 2010, at 12:59 AM, Josh Godsiff wrote: I avoid Apple products like the plague, so perhaps I'm missing some info here, but what's wrong with simply getting the user to download the file in the normal fashion? - Josh On 9/8/2010 3:11 PM, Breton Slivka wrote: The iPhone has a 5mb upper limit per page. I think the ipad's limit is 10mb but I am not sure. So in other words, no. -Breton On 09/08/2010, at 2:55 PM, Andrew Harrisand...@woowoowoo.com wrote: Hi all, I'm asking around the traps on a question which has come up at work. We want to develop an iPad app to will allow users to download from a website (like a synch) large quantities (hundreds of MB) of documents (pdf and word) for reading offline. Is the offline storage tool in HTML5 designed for this sort of heavy lifting? are there storage limitations? on an iPad? I've found a few examples of the tool in action and read bits and pieces, but it all seems to be about storing small chunks of data, not humunguous great whumps of it. -- Andrew Harris and...@woowoowoo.com http://www.woowoowoo.com ~~~* ~~~ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] @media ordering in stylesheet
Hi all,
Does @media rule ordering in a stylesheet matter? For example, given the
following order:
@media print {
body {
#FF;
}
}
@media all {
body {
#99;
}
}
Will @media print override the @media all in this ordering?
Googling around, I've not found a clear answer to the question. So, any help is
appreciated.
Thanks in advance,
jody
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] @media ordering in stylesheet
Thanks for the responses. I needed the experts in the group to confirm my suspicions. Best, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] EM bug in Safari 5?
If this helps: my MacBook Pro is about 2 months old and Safari's default is 16px. -jody On Jul 30, 2010, at 11:38 AM, tee wrote: I had this issue to then I checked safari's default font size and it was set to 12px instead of 16px like the other browsers. Once I changed that setting to 16px then they all looked the same. I would suggest verifying in your browsers that they all have the same px size set for their default font size before testing. Thanks for bringing this up. I changed it and now Safari renders the width similar to others. This is very strange! The font size in my Safari is 14px. I'd just had this computer about 6 months ago, and have no memory I altered the font size for the reason I did in previous machine (mentioned in my previous email). Other browsers have default 16px. Do you have idea how Safari makes the calculation that resulted 121px differences with 14px font size setting when width is set to 62em. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] link rel=stylesheet question
Many thanks to those who respond to the link rel=stylesheet question, Best, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] link rel=stylesheet question
Hello all, In a stylesheet link, does the order of rel, href and type affect how a browser understands, loads, etc. a stylesheet? I usually see the rel attribute first, as in the example below, but does the order of attributes matter or is the order convention, convention meaning, that's what most people do? link rel=stylesheet href=screen.css type=text/css / Thanks in advance, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Overflow hidden and floated divs
I asked a similar question back in February and this link helped explain it:
http://www.quirksmode.org/css/clearing.html
-jody
On Jul 15, 2010, at 8:11 AM, Stevio wrote:
I have a row of floated list items inside a container with height 1.2em,
which is inside a parent div with a background colour.
e.g. something like this (not the actual HTML of course ;) -
div with background colour
ul with height 1.2em
li floated/li
li floated/li
li floated/li
/ul
/div
If the floated list items were too wide, the rightmost list item jumped down
beneath, but the container did not expand so it looked bad.
However, if I add overflow:hidden; to the parent div, then the rightmost
list item still jumps down, but now the box expands down the way, so it
looks a lot better.
My question is why does it do this? I have looked up what overflow hidden is
meant to do and from what I read it sounds like the content should just get
clipped at the right hand side and not be shown. Why is it causing the box
to expand down the way?
Thanks.
Here is the CSS:
#navigationbar {
background-color:#DEDEDE;
overflow:hidden;
}
#navigationbar ul {
padding: 0.2em 0 0.2em 0;
margin: 0px;
list-style: none;
height:1.2em;
}
#navigationbar ul li {
padding: 0;
margin: 0;
display: block;
float: left;
}
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
[WSG] the mysteries of overflow: hidden
(I'm a list lurker. Also, apologies if this has been covered before.) In CSS, setting a div to overflow: hidden solves a problem it shouldn't--at least from the name of the property and value, it seems like it shouldn't. Often I'll have text, e.g. an h1, overflowing its containing/parent div, but setting the containing/parent div to overflow: hidden causes the parent div to set its height in a way that the formerly overflowing text no longer overflows. I've seen this happen for years. Another developer showed me this fix years ago. But over the years, I've never read an explanation why overflow: hidden fixes a problem its name implies it wouldn't. Have others seen this? Any explanations? -jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Appropriate postings
I'm a lurker on the list, but primarily because the list, so far, has seemed like a place where people come for help solving specific, remedial problems with long-standing (in internet-time) solutions well-documented on the internet and in books. On 8/5/08 11:10 AM, Rick Faircloth [EMAIL PROTECTED] wrote: And I would like to know what a list on any subject is for if not for helping people understand the most basic principles and application of a give practice. A list on any topic must embrace all level of participants, beginners and advanced, alike. If we think of the list as a classroom, a teaching environment, then it's standard practice to have separate beginning, advanced, etc. classes. At the university level, for example (in the US), classes at the 100 level tackle different issues than classes at the 200, 300 and 400 level. A list on a topic isn't required to embrace all levels of expertise. I've participated in many mailings lists where some requests for basic help were considered off-topic. Requests for help when answers can be found by via searches or reading books were often seen as inappropriate. I'd advocate (at the risk of sounding snobby), as some have suggested, for different lists--one to accommodate beginners and another to accommodate other developers interested, not in help with standards, but in the standards themselves. Anyone who thinks a list about web standards should not first have as its mission to teach and clarify the basics of the tools of standardization, such as CSS, is mistaken. Unless expressly stated, a list must cater to the lowest common denominator of its participants, not the highest. By doing so, those on the bottom are lifted up, instead of always being pushed down and kept in the dark. To think a list about web standards doesn't need to have teaching as its first mission is not mistaken, it's considering that a different goal or multiple goals might be acceptable. Web standards are not new, though they may be new to some list users. Teaching can be a function, but if helping others with the basics is its sole function, as it's becoming here, it neglects another portion of the list's members, those who have been using web standards since their inception and hope to have extended discussions about, for example, XHTML vs. HTML5, CSS3, current and upcoming browser implementation of standards, emerging standards and so on. -jody -- Jody Tate http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] html vs. html
After much googling around (I was fascinated by this question) and much reading of various W3C documents here and there, I can say with about 97.3% certainty that the W3C has never drafted a recommendation that standardized file extensions. Most of their recommendations include URI examples that use the .html extension and the site itself appears to use .html extensions: http://www.w3.org/TR/xhtml1/Cover.html. The real story of why .htm and three letter extensions were ever used is told in a round about way here: http://en.wikipedia.org/wiki/Filename_extension . Given the history of filename extensions, I can see how someone might think that a three-letter extension is required (and maybe--for some strange reason--the server's settings do require html to be served as .htm and .html files are served differently). Whatever the case, the W3C doesn't recommend .htm as a standard. -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] premature to test/worry new site for IE8?
IE8's default setting will be to render web pages in standards- compliant mode. You can opt out of standards compliance with a meta tag. It was originally announced as the reverse. They changed their mind once the mob headed toward the castle in Redmond with pitchforks. Like most of us, If I could bill MS for all the time I've spent debugging/hacking web pages for IE, I'd be a rich man. But I've been using and testing the IE8 beta since it was released, and I'd hazard that if you're writing standards compliant (x)html and css, all should be well (more or less) with the final release. The efforts of the IE development team, while not always stellar in the past, genuinely seem to be going in the right direction. They're working with the Web Standards Project and other groups to ensure IE8 isn't the disaster that IE6 and 7 have been. -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ On Mar 21, 2008, at 3:52 AM, tee wrote: I am about to start coding for a new site, and client asked me to make sure my code will work for IE8, meaning when IE 8 comes out, she doesn't need to pay me extra to fix any problem that may occur in IE 8. Client is from a web media company, though I understand her concerns and that she has to answer to her client, but I just don't know how or if I should commit to such 'expectation'. Last time with IE 7, there was no problem and none of the sites I coded for her break when IE 7 came out. I think this version targeting thing really got people worry. Say, I code my CSS with best practice just like I'd always do, and treat IE browsers with CC should it be needed. Do I need to worry anything with IE8? It didn't occur to me to worry anything at all until client was making this request. Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] generated source
Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. I'm asking because I'm working on a web application for browsing network devices (close to 9000 routers, switches, WAPs, etc.) that relies on JavaScript (some homemade JS, jQuery, Ajax and JSON) to build virtually all the XHTML. Yet, when I view source via the debug inspect element feature in the latest release of Safari or using Pederick's web developer Firefox add-on, closed tags become unclosed. For example: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Becomes: meta http-equiv=Content-Type content=text/html; charset=UTF-8 Yet viewing generated source in Firebug, that same meta tag remains closed. Firebug, however, doesn't have (or I haven't noticed?) a way to copy and paste source code for direct input validation to the W3C validator. This, then, is the ultimate goal: to get the generated source, copy it and paste it into a validator. I validated with static mockups prior to de-building the XHTML and giving it over to JavaScript, but I want to validate now to make sure I'm staying on track. Have others run into this problem? Thanks in advance, Jody -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] generated source
Thanks, Paul, for the suggestion. Doctype, I don't think, is the issue. The doctype is set in the static XHTML that the Ajax builds on as XHTML strict. However, most generated source views remove the doctype, a phenomenon I asked about here: http://ask.metafilter.com/84314/Where-does-the-DTD-go . The W3C validator lets you re-declare a doctype if one is missing, http://validator.w3.org/#validate_by_input+with_options , but even using that option, many of my tags are still already unclosed from the generated source view. -jody On Feb 26, 2008, at 11:37 AM, Paul Bennett wrote: Hi Jody, I recall having a similar problem. The issue came down (from memory) to the doctype I was using. I was closing elements in xhtml style, while the doctype I was using was html. Firefox was happily removing the extraneous closing elements in the rendered source to fit the doctype. :) Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
