New Safari Features In Latest Leopard Preview?

[willybNL]

Can't wait for LiveBookmarks (RSS inside bar like in firefox) to get into safari...

 

[aegisdesign]

That's why we use style tags to set a default font (yes, even in text areas) or fixed margins. If the W3 gives us the tools, then why should the browser render them void? That just makes no sense.

Safari is implementing a CSS3 feature with resizeable text areas. Apart from that, if your site design relies on fixed font sizes and text area sizes, they'll just break when the user Command-+/-'s the page. It will only break your site design if your site design is badly designed in the first place.

If you're worried about text areas overflowing other page elements then you can still use max-width and max-height to restrict growth and/or the overflow attribute so that scroll bars get introduced.

As one person pointed out in this thread, see the two arrows up ad down on the first line of the toolbar in this very textarea you type in to. It's very useful with long posts. That's why expandable text areas are a good idea.

It's actually not hard to do either. Look at http://www.aegisdesign.co.uk/examples/textarea/textexample.html and view the source for a simple example.

I'd disagree that designers should be making text areas 100% wide though. I've a 2560 wide screen. That'd be silly. Letting users on the other hand size it themselves and giving designers the tools to accommodate resizing is the way to go.

That's the most ridiculous statement I've read in this thread so far - and there are quite a few.

It's called the 'semantic web'. You may want to look it up. Decent web designers have been designing this way for some time where they can and the W3 want everyone to go this way.

The problem is of course with any of these new W3 features is that Microsoft have barely reached the basics in the CSS 2.1 standard yet in IE7. The chances of them supporting CSS3 anytime soon are slim. That means we'll still as designers have to support the older standards and only enlightened Firefox/Safari based designers will add on CSS3 based features should they prove compatible with IE7 and even IE6.

 

[IlluminatedSage]

safari needs a little work on it. Right now I prefer Firefox because of the tabbed window function and even more so because i can add search engines within the same window, such as google, yahoo, amazon, ebay, IMDB and webster dictionary.

the ease of use, and the fact that my Yahoo Toolbar makes it easy to share my very same bookmarks among several computers.

 

[c-Row]

It's called the 'semantic web'. You may want to look it up. Decent web designers have been designing this way for some time where they can and the W3 want everyone to go this way.

I think this makes us web programmers rather than designers.

It will only break your site design if your site design is badly designed in the first place.

Then please go visit www.csszengarden.com and see how user-applied changes break their designs to the point where elements are covered by others. Those designs usually apply to the W3 standards, and I bet they are far better at this things than either you or me.

 

[aegisdesign]

safari needs a little work on it. Right now I prefer Firefox because of the tabbed window function and even more so because i can add search engines within the same window, such as google, yahoo, amazon, ebay, IMDB and webster dictionary.

Safari has tabs or do you mean something else? You can also add search engines to the searchbox using one of the many plugins at http://www.pimpmysafari.com/

the ease of use, and the fact that my Yahoo Toolbar makes it easy to share my very same bookmarks among several computers.

.Mac does the same. Obviously it's not free though.

I'd imagine you could do the same by sticking an alias to Safari's .plist on a net share but it certainly could be easier than it is now.

Personally, I prefer Safari because it integrates with OSX's spell checker, supports Bonjour, behaves like a proper OSX app with OSX native widgets and looks better.

 

[aegisdesign]

I think this makes us web programmers rather than designers.

No. It's fairly common sense stuff really to stick code in like class="title" instead of class="blue" to infer structure in a document, not the design.

Then please go visit www.csszengarden.com and see how user-applied changes break their designs to the point where elements are covered by others. Those designs usually apply to the W3 standards, and I bet they are far better at this things than either you or me.

Whilst I think csszengarden has some pretty designs, there's more to design than just how something looks. If their designs break because of users resizing the page, then their design is broken. That doesn't take away from the artwork, which is often excellent.

csszengarden is also just ONE underlying document structure and not a terribly practical one either. It's there to showcase what can be done just with CSS, not how to design a practical semantically led page.

 

[c-Row]

No. It's fairly common sense stuff really to stick code in like class="title" instead of class="blue" to infer structure in a document, not the design.

I agree - especially about the class="blue" example. This will lead into problems as soon as the element should be given another colour in the future. However, the original post reads like "Hey, let's say this <element> is LARGE and let the browser decide what a LARGE <element> should look like, how large it should be, etc..."; and that's what I criticise.

csszengarden is also just ONE underlying document structure and not a terribly practical one either. It's there to showcase what can be done just with CSS, not how to design a practical semantically led page.

Guess the main problem is that they can't update the initial document structure afterwards - otherwise there would be problems with all the designs.

 

[Yvan256]

[...] This would just mean us designers would have to spend that much more time envisioning what would happen if a user resized every form element on every page and incorporating it into our layouts. This is why I hope there's a way to disable it outright.

You already have to envision what will happen when a user changes the text size. The web is not print or TV, it's supposed to be flexible and to be controlled by the user, not the designer. Your website should look good wether the user changes the text size, disables plug-ins, disables images or even disables CSS.

Granted, the website won't look exactly the same in each case, but the content and the structure should be visible in all cases if the website is coded properly. That's the power of CSS and structured content.

Using javascript to disable a browser feature (like the useless "disable right-click" one) is working against your viewers. A simple "disable javascript" will also bypass your script.

 

[Yvan256]

Then please go visit www.csszengarden.com and see how user-applied changes break their designs to the point where elements are covered by others. Those designs usually apply to the W3 standards, and I bet they are far better at this things than either you or me.

Having valid (X)HTML/CSS code doesn't mean it's well-coded. Some designers still think that webpages are static images where they (should) have pixel-perfect control. I hate those websites, some even go to the length of putting actual text content inside a GIF file because the browser couldn't render their 5-pixels-high font correctly.

CSS Zen Garden shows how the web should be coded (XHTML structured content styled with CSS), but some of the designs (CSS files) are bad (yet use valid CSS code).

If you view CSS Zen Garden with CSS disabled, you'll still have access to the content. It won't be pretty, but it'll be there. Content is more important than style (style with no content is useless).

 

[kcbruce]

resizable text area is great, but...

What I've been waiting for is true javascript support for wysiwyg textarea editors. I run a Mac blog site and I have to ask users to use Firefox. It seems a little sucky to do that for a Mac specific blogger site. Since Safari 1.3 Apple said they included the nessesary "hooks" for these editors, but no one has been successful in getting any of them to work in Safari.

I downloaded the latest nightly build of Webkit and it still doen't work

 

[Yvan256]

No. It's fairly common sense stuff really to stick code in like class="title" instead of class="blue" to infer structure in a document, not the design.

I'm sorry to say that "class=title" is not structure either. It may look structured to you in the code (especially compared to "class=blue"), but it has no meaning as far as content structure goes. You should be using the headings tags (H1, H2, etc) and then apply styles to those tags.

Unless you're using <h1 class="title">, in which case I'll have to say "redundant". ;-)

 

[nevir]

What I've been waiting for is true javascript support for wysiwyg textarea editors. I run a Mac blog site and I have to ask users to use Firefox. It seems a little sucky to do that for a Mac specific blogger site. Since Safari 1.3 Apple said they included the nessesary "hooks" for these editors, but no one has been successful in getting any of them to work in Safari.

I downloaded the latest nightly build of Webkit and it still doen't work

Considering Apple is releasing what looks like a full-page wysiwyg editor, I don't think you'll have to wait too much longer (Leopard) for that type of wysiwyg support.

 

[nevir]

I'd disagree that designers should be making text areas 100% wide though. I've a 2560 wide screen. That'd be silly. Letting users on the other hand size it themselves and giving designers the tools to accommodate resizing is the way to go

At the same time, it's kinda silly to view most web pages at 2560 wide, even 1200+. At that point a paragraph is usually only one or two lines, forcing you to do quite a bit of tracking to read what you want. If you're comfortable viewing the text that way, why not edit it that way as well?

But I definitely agree that letting the users resize the textareas inside the page is a great usability feature. Just was trying to point out that there are already (simple) solutions to the issue.

 

[aegisdesign]

What I've been waiting for is true javascript support for wysiwyg textarea editors. I run a Mac blog site and I have to ask users to use Firefox. It seems a little sucky to do that for a Mac specific blogger site. Since Safari 1.3 Apple said they included the nessesary "hooks" for these editors, but no one has been successful in getting any of them to work in Safari.

I downloaded the latest nightly build of Webkit and it still doen't work

Actually, there are a few that do work, mostly commercial like Asbru's editor - http://editor.asbrusoft.com/

The problem is, the support in Safari still isn't brilliant and the other guys like FCK, TinyMCE etc so far aren't willing to work around the bugs knowing that Apple is fixing them in a forthcoming release anyway.

 

[DPazdanISU]

Sounds awesome, but I'll still stick with Camino until Safari speeds up a bit and is more stable. Those were my only two issues.

Fishes,
narco.

I suggest buying a mac pro with 16gb ram that way you can use safari
jokes aside, I use it on my g4 mini and its fine, I'm sure camino is faster but I guess I got used to safari's feel

 

[aegisdesign]

I'm sorry to say that "class=title" is not structure either. It may look structured to you in the code (especially compared to "class=blue"), but it has no meaning as far as content structure goes. You should be using the headings tags (H1, H2, etc) and then apply styles to those tags.

Unless you're using <h1 class="title">, in which case I'll have to say "redundant". ;-)

There are other places you might use class="title", eg. in a form such as the form you type replies to posts in. It has a 'Title:' input field. I just meant class="title" as an example of semantic design.

 

[pewtermoose]

What I've been waiting for is true javascript support for wysiwyg textarea editors. I run a Mac blog site and I have to ask users to use Firefox. It seems a little sucky to do that for a Mac specific blogger site. Since Safari 1.3 Apple said they included the nessesary "hooks" for these editors, but no one has been successful in getting any of them to work in Safari.

I downloaded the latest nightly build of Webkit and it still doen't work

WYSIWYG support is there and is improving all the time. The developers realize this is is an area of concern and it is on their compatibility hit list. The latest TinyMCE development sources work very well in the WebKit nightlies.

If you discover a bug in your website, please report it using the guide on webkit.org. Bugs can't get fixed if the developers don't know about them.

 

[Yannick]

Those three new features look very good to me. It's going to be so exciting to try out all the new things when Leopard comes out.

 

[jrmontag]

new Google search?

Perhaps I missed part of the new Google search feature in the new version of Safari, but isn't there an already-existing (and awesomely functioning ) Google searchbar in there? I'm still using Panther with Safari v1.3.2!

 

[skwoytek]

Resizing Textarea

I welcome this feature.

People want a layout with usability, not a design that looks just so. Still, both are easy to achieve if your skilled.

I always surf with my text zoomed at least one level which is available on every browser - this messes up more wabpages than it should. Some of my favorite websites have comment textareas with 3-4 lines of text and are as few as 20 characters wide. I always end up writing in Pages and copying into the textarea.

 

[SpanishUser]

I did, in fact, mean using JavaScript on page load to disable the user from changing the size of the textarea, not within my browser. It's like using CSS to disable the dotted border Firefox puts around links when they are active.

Form elements, and the divs that contain them, often need either fixed widths or have widths that are proportional to their containers.

Take Google. Depending on how the layout is set up (this is just hypothetical), resizing the search box would push those three links next to it off into oblivion if they were all in a div that was fixed or proportional to the page width. It doesn't matter if Safari "dynamically redraws the page" since the div would still be calculated to be the same. Worse yet, depending on its overflow attribute, they could be pushed onto a new line.

I'd really not like to see Safari become the next IE 5. It already has its share of JavaScript bugs. This would just mean us designers would have to spend that much more time envisioning what would happen if a user resized every form element on every page and incorporating it into our layouts. This is why I hope there's a way to disable it outright.

I hope you remember the user CSS take precedence, the user can choose a minimum font size and run an extension like nonscript to firefox so by default
no javascript would run.

The Web is based in that is the reader the one that decide how a page would look if you do not like that begin to design magazines or book.

Note: the noscript funcinality is something I would like to see added to safari.

 

[Warbrain]

All fine and dandy that they're putting in new features...

but make it stable and make it compatible with most of the websites out there. Safari is so behind some other browsers...

 

[weldon]

Perhaps I missed part of the new Google search feature in the new version of Safari, but isn't there an already-existing (and awesomely functioning ) Google searchbar in there? I'm still using Panther with Safari v1.3.2!

The new search feature is not a new Google search feature. I'm pretty sure what they mean is that you can search the text in the current page by typing and have a little find search box come up at the bottom of the window like it does in Firefox (rather than having a floating dialog box for find). One blogger mentioned it would work like spotlight and shade everything else so that the found search terms were highlighted.

 

[morespce54]

Web designers will just have to become more sophisticated. They will have to learn to work with relative units. For example a button size should be specified as "m times the lenght of this string in the current user specified font" and a image size rather then being fixed might be "80% in the frames width as set by the user

The would... If the browsers (not to mention IE) could properly implement the "basic standards" for once...

Imagine everybody writing something in C++ but with their own (and only) version...

 

[FaasNat]

Here's hoping Safari implements some sort of cookie manager and popup window blocker perferences similar to how Firefox's are.